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In this Issue 




The phenomenal growth and complexity of computei networks has created a 
wealth of opportunities for communication and resource sharing and a multitude 
of concerns about privacy and security. The Open Software Foundation's Distrib- 
uted Computing Environment (DCE) was developed to fill the need for a stan- 
dardized approach to creating and executing secure client/server applications 
in complex, highly networked environments. Applications developed using the 
DCE software system are portable and interoperable over a wide range of com- 
puters and networks. Applications running in DCE are also able to share data 
and services efficiently and securely regardless of the number of computers 
used or where they are located. HP, like some other companies in the computer 
industry, has contributed technologies to DCE and released several versions of DCE as a product for the 
HP-UX* operating system. The first eight articles in this issue describe the fundamental elements of 
DCE and the enhancements made to DCE by HP in the areas of application development and security. 

DCE is based on the client/server model in which an application's functionality is divided between cli- 
ents, which represent users, and servers, which provide the services requested by users. In a DCE envi- 
ronment, there might be several thousand host systems, some of which might be from different vendors, 
and many different categories of users and applications. To deal with this heterogeneous and diverse 
environment, DCE defines a basic unit of operation and administration called a cell, which allows users, 
systems, and resources to be grouped together according to their needs and common interests. The 
client/server paradigm and the concept of cells are introduced in the article on page 6. This article also 
introduces features in DCE that facilitate concurrent programming, DCE client/server remote communi- 
cation, time synchronization between distributed hosts, and handling a distributed file system. 

Encouraging others to adopt a new technology is made a lot easier if you have examples of its use. HP's 
information technology group has adopted DCE and has begun to move HP's legacy information technol- 
ogy system to the DCE architecture The article on page 16 describes the issues and rationale that led 
HP to adopt DCE for information technology, and the administration and planning issues associated with 
this transition. 

A typical DCE cell can span several systems and networks. To find users, files, devices, and resources 
inside and outside these cells requires a naming system that allows each cell and the objects contained 
inside it to have unique names, and a directory service that can cope with different naming systems. The 
article on page 23 describes the DCE directory services and the article on page 28 describes the X/Open 1 
Federated Naming specification, which defines a uniform naming interface for accessing a variety of 
naming systems. 

One of the biggest issues surrounding networked systems today is security. How do we protect an 
open, distributed system from unauthorized access and abuse? DCE provides a collection of services 
for developing security mechanisms to protect against unauthorized access. The user's password is the 
primary key for getting into a system, and in some situations users may be required to enter several 
passwords during a session to gain access to different applications or other parts of the system Each 
time the user is required to enter another password, the system is made vulnerable to an opportunity for 
hostile invasion. The article on page 34 describes the HP Integrated Login product, which is a single-step 
login facility in which the user enters a password once at login time, and this password is used to grant 
access to the HP-UX machine as well to verify access to other secured parts of the system. The security 
protocol that takes over after the password is entered is described in the DCE security service article on 
page 41 The DCE security service authenticates a legitimate user and then checks to make sure that the 
user is authorized to have access to the requested services. The article on page 49 describes one of 
these authorization mechanisms called access control lists (ACLs). ACLs are lists of permissions that 
belong to certain users or groups of users. 
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DCE provides several very powerful facilities for creating DCE client/server applications However, the 
interfaces to some of these facilities are quite complex The article on page 55 describes the HP Object- 
Oriented DCE lOODCE) product, which is an object-oriented library of C+- classes that hide the program- 
matic complexity of DCE from developers to ease the development of distributed applications 

Transaction processing systems are used m large enterprises to store, retrieve, and manipulate data 
reliably in the face of concurrent access. The HP Encina/9000 transaction processing monitor described 
on page 61 provides an environment for developing distributed OLTP (online transaction processing) 
applications. Encina/9000 uses many of the features of DCE to create its distributed, client/server 
capabilities. 

One of the biggest challenges in software development is still testing the product. This challenge is even 
more daunting in distributed client/server environments. In the article on page 75 the authors describe 
how the testing environment for nondistnbuted, procedural software is not applicable to a distributed 
environment The article describes the evolution of a reusable, ob|ect-onented testing environment called 
the object testing framework (OTF). Although OTF was designed for a non-DCE-based product, the con- 
cepts and tools developed for OTF are applicable to products that might be based on DCE. 

Bar code readers and magnetic strips are so commonplace today that their usefulness in areas such as 
banking, manufacturing, and retail is taken for granted However, these technologies do have their 
limitations in that they require a direct line of sight and a relatively clean, benign environment. Another 
technology called RF/ID (radio frequency identification), which is a combination of two components — a 
transmitter and a receiver — overcomes the limitations of these other technologies The article on page 
94 describes the HP HSMS-285x silicon detector diodes designed for use in RF/ID applications. 

In today's modern hospitals patients who have to be monitored are connected to an array ol high-tech 
patient monitoring equipment. Aware of the intimidating look of all this equipment, many hospitals are 
trying to create a more friendly environment in their labor and delivery departments by reducing the 
amount of technology at the patient's bedside. The HP Series 50 T fetal telemetry system, which is de- 
scribed in the article on page 82, is a step in this direction. The HP Series 50 T combines external and 
internal fetal monitoring in a lightweight, portable transmitter. 

C.L Leath 
Managing Editor 



Cover 

A highly internetworked distributed computing environment made up of clients and servers is shown in 
the background. Appearing in the foreground is the software aiclutecture foi one pair of client and 
server systems. 



What's Ahead 

In the February issue we'll have several articles on the design of the HP 9000 J-class workstations and 
K-class servers, symmetric multiprocessing computer systems based on the HP PA7200 CPU, a superscalar 
PA-RISC processor. We'll also have an overview of code-domain power, timing, and phase measurement 
algorithms in the HP 83203B CDMA cellular adapter. There'll be a design article on the HP HDMP-1512/14 
1 0625-G bil/s Fibre Channel chipset and an article on applying the software code inspection process to 
hardware descriptions. 



Correction 

In the August 1995 issue, the curve nearest the vertical axis in Fig 2 on page 22 should be labeled 

V.fext- 
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DCE: An Environment for Secure 
Client/Server Computing 



The Open Software Foundation's Distributed Computing Environment 
provides an infrastructure for developing and executing secure 
client/server applications that are portable and interoperable over a wide 
range ul computers and networks. 

by Michael M. Kong 



The Distributed Computing Environment (DCE) is a suite of 
software Thai enables networked computers to share data 
and services efficiently and securely. The initial specification 
and development of D< E took place in 1885} under the aegis 
of the Open Software Foundation (( )SF) through the ( )SF 
RFT (request for technology) process. Several companies in 
the computer industry, including HP, contributed technologies 
to DCE. Ill' has since released several versions of DCE as a 
product for HP-UX* systems, with added enhancements 
particularly in tools for administration and application de- 
velopment. IIP remains active in the development of future 
OSF DCE releases. 

The major technologies in DCE include: 
Threads. A library of routines that enable several paths of 
execution to exist concurrently within a single process. 
Remote Procedure Call (RPC). A facility that extends the 
procedure call paradigm to a distributed environment by 
enabling the invocation of a routine to occur on one host 
and the execution of the routine to occur on another. 
Security. A set of services for authentication (to verify user 
identity I. authorization (to control user access to data and 
services), and account management. DCE security services 
are described in the article on page 41. 
Cell Directory Service (CDS). A service that maintains a data- 
base of objects in a DCE cell and maps their names (which 
are readable by human users) to their identifiers and loca- 
tions (which are used by programs to access the objects). 
CDS is described in the article on page 23. 
Global Directory Service (GDS). A service that maintains a 
database of objects that may exist anywhere in the world 
and enables DCE programs to access objec ts outside a cell 
GDS is also described in the article on page 23. 
Distributed Time Service (DTS). A service that synchronizes 
clocks on DCE hosts with each other and. optionally, with 
an external clock. 

Distributed File Service (DFS). A service that allows DCE 
hosts to access each other's files via a consistent global file 
naming hierarchy in the DCE namespace. 

The HP DCE product adds several features to the OSF DCE 
offering, including: 

An integrated login facility that enables HP-L'X login pro- 
grams to perform DCE authentication for users. This feature 
is described in the article on page 28. 
A DCE cell configuration utility integrated with the HP-UX 
system administration manager (SAM). 



An object-oriented 1 >( E ( HP Ol )DCE) programming envi- 
ronment that eases DCE application development for C++ 
programmers. HP OODCE is described in the article on 
page 55. 

Integration of DCE application development tools with the 
Soft Bench product and extensions to these tools that sup- 
port tracing and logging of distributed application activity. 

This article describes the DCE client/server model, intro- 
duces DCE cells, and provides an overview of tour technolo- 
gies in DCE: threads. RPC (remote procedure calls). DTS 
(distributed time service), and DFS (distributed file service). 
Articles elsewhere in this issue describe DCE security, the 
IK E directory services, and other aspects of the IIP DCE 
product. Unless otherwise specified, these articles describe 
version 1.4 of HP DCE/9000 as released Tor Version 10.10 or 
the HP-UX operating system. 

The Client/Server Model 

DCE applications and the various components of DCE inter- 
act according to a client/server model. Functionality is orga- 
nized into discrete serv ices; clients are users of services and 
servers are providers of services. A client program issues 
requests for services and a server program acts on and re- 
sponds to those requests. A program may play both client 
and server roles al once by using one service while it pro- 
vides another. For example, in a distributed application that 
relies on secure communication, both the client and server 
sides of the application also act as clients of DCE security 
services. The client/server model insulates the users of a ser- 
vice from the details of how the service is implemented, 
allowing the server implementation to be extended, relo- 
cated, or replicated without perturbing existing clients. 

To make the service abstraction work in practice, clients anil 
servers must agree on how they will interact. They agree on 
what requests the client can make of the server, and for 
each request, what data will Bow between them In DCE, 
these aspects of a service are described in a definition of the 
client/server interface written in the RPC Interface Definition 
Language (IDL). The DCE application development software 
ensures that client and server programs will adhere to the 
interface definition. Given an RPC interface definition for a 
service, an application developer can build and execute 
clients and servers on different DCE implementations, and 
the resulting programs will interoperate correctly. 
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In addition to RPC interfaces for distributed services. DCE 
defines application program interfaces I APIs) that applica- 
tions invoke when they wish to use DCE services- In the 
example of the secure application mentioned above, the 
application client and the application server will faith invoke 
DCE security routines provided by the DCE run-time library. 
The library will interact as necessary with the DCE security 
server on behalf of the application program. The existence 
of standard APIs for DCE services ensures the portability of 
applications across all DCE implementations. 

DCE Cells 

DCE services are deployed in administrative units called 
cells. A cell can encompass one host or many thousands of 
hosts in a single local network or in an internetwork span- 
ning continents. The grouping of hosts into a cell does not 
necessarily follow physical network topology (though net- 
work performance characteristics may make some groupings 
more practical thai) others ). Rather, a cell is usually defined 
according to administrative boundaries. A cell contains a 
single security database and a single Cell Directory Service 
(CDS) namespace, so all users and applications within a cell 
are subject to the same adniinistrative authority, and re- 
sources are more easily shared within the cell than between 
cells. 

Fig. 1 shows a relatively simple DCE t ell containing servers 
and clients. The minimal set of services in a cell consists of 
a security server, a CDS server, and some means of synchro- 
nizing time among the hosts, hi this cell, the security and 
CDS databases are replicated for increased performance 
and reliability, so there are two security servers and two 
CDS servers: The DCE time service, DTS, is used to synchro- 
nize chicks throughout the cell with an external time source. 
( )ther DCE services such as DPS and CDS (Global Directory 
Sen ice) need not be configured in a minimal DCE cell but 



can be added at any time. A DCE-based application is 
installed in the cell in Fig. 1. with an application server run- 
ning on an HP 5)000 Series 800 server and application clients 
running on PCs and workstations. Finally, each host in the 
cell has a DCE nut-time library and nuts DCE client daemons. 

Threads 

In a distributed environment the need often arises for one 
program to communicate concurrently with several others. 
For example, a server program may handle requests from 
many clients. The DCE threads facility provides the means 
to create concurrent threads of execution within a process 
and hence eases the design and enhances the performance 
of distributed applications. The threads facility is not itself 
distributed, but virtually all distributed services in DCE rely 
on threads, as do most DCE-based applications. 

P< ISLX (Portable < 'penning System Interface)' has defined 
an industry-standard programming interface for writing 
multithreaded applications: the Pi )SIX 100:1. la specification. 
DCE threads is a user-space implementation of Draft -I of 
this specification. 

One way to introduce die notion of a thread is to describe 
an ordinal} singled-threaded process and contrast this with 
a multithreaded process. A process is a running instance of 
a program. When a process starts, the text of the program is 
loaded into the address Space of the process and then in- 
structions in the program text are executed until the process 
terminates. The instructions that are executed can be thought 
of as a path or thread of execution through the address space 
of the process. An ordinary process can thus be considered 
to be single-threaded. 

A threads facility allows several threads of execution to exist 
within one process. An initial thread exists when a process 
Starts, and this thread can create additional threads, making 



CDS Server 
GDA Daemon 
DTS Server 
DCE Client Daemons 
and Run Time Library 
Security Server 
(Master) 



CDS Server 
DTS Time Provider 
DTS Server 
DCE Clienl Daemons 
and Run Time Library 
Security Server 
(Slave) 




r 




DTS Clerk 

DCE Client Daemons 
and Run Time Library 
Application Server 



DCE Software 









e 



















HP9000Senes 800 
Machines 



r \ 

PC 





Network 



Clients 



Workstations 



PC 



PC 



Application Clients 
DTS Clerk 

DCE Client Daemons 
and Run-Time Library 



DCE Processes 
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ih<* process multithreaded. Each tliread executes indepen- 
dently and has its own stack. However, the threads in a pro- 
cess share most process resources, such as user and group 
identifiers, working directories, controlling terminals, file 
descriptors, global Variables, and memory allocated on the 
heap. 

Resource sharing and concurrent execution can lead to 

several performance benefits for multithreaded programs: 

Threads can be created, synchronized, and terminated 

much more efficiently than processes. 

If one thread blocks, waiting for [/( ) or for .Mime resource, 

other threads can continue to execute. 

A server program can exhibit belter responsiveness to 

clients by dedicating a separate thread to each client 

request. The server can accept a new request even while it 

is still executing older requests. 

On a multiprocessor computer, several threads within a 
process can run in par allel on several processors. 

Of course, the execution of threads in a process can be truly 
concurrent only on a computer that has multiple processors 
and has a threads implementation thai can take advantage of 
multiprocessing (even then, concurrency is limited by the 
number of processors). In reality, the threads in a process 
take tarns executing according to a scheduling policy and a 
scheduling priority (hat are assigned to each thread. Depend- 
ing on the policy that governs a thread, the thread will run 
until it blocks, until it consumes a time slice that was allo- 
cated to it. or until it voluntarily yields the processor. A con- 
text switch then occurs, and (he next thread to execute is 
chosen from a queue of threads that are ready lo run, based 
on their priorities. 

Threads programmers can use condition variables to synchro- 
nize threads so that a thread will run only after a specified 
condition has been satisfied. A thread can wait on a condition 
variable either for a specified rime to elapse or for another 
thread to signal that variable. The waiting thread does not 
reenter the ready queue until the condition is satisfied. 

Because threads run concurrently and share process re- 
sources, programmers must protect regions of code thai 
access shared resources. For example, if a context switch 
occurs in code that manipulates global variables, one thread 
may have undesired side effects on another thread. The 
threads API allows programmers to use mutual exclusion 
(nuitex) locks to prevent such effects. Only one thread can 
hold a given mutex lock at any time, and any other thread 
dial attempts to take the lock will block until the lock is 
released, so only the thread that holds the lock can execute 
the critical region of code. 

Like global data, static data can be a conduit for side effects 
between threads when a context switch occurs, and this 
imposes another constraint on code that executes in multi- 
threaded processes. Routines that can be called by multiple 
threads must not return pointers to static data 

The requirements mentioned above for code in multithreaded 
programs apply not only to DCE executables and DCE appli- 
cation programs, hill also lo any Libraries used by those pro- 
grams. A library is considered thread safe to the extent that 
it behaves correctly when used by a multithreaded program. 
The HP-UX operating system defines several levels of thread 
safeness for libraries. The IIP-l'X C library, for instance, can 



safely be called by several threads in one program, whereas 
some other libraries can be called by only one thread per 
program. 

A kernel-space implementation of the final POSLX threads 
specification may ultimately replace die user-space imple- 
mentation of Draft -1 that is currently supplied with HP Dt'E. 
Kernel threads would make true concurrency possible on 
multiprocessor computers and probably improve perfor- 
mance on uniprocessor machines as well. 

Remote Procedure C all 

The remote procedure call (RPC) facility is the basis for all 
DCE Client/server communications and therefore is funda- 
mental to the distribution of services in DCE applications 
and in DCE itself. 

The RPC mechanism enables a procedure inv oked by one 
process (the client I lo be executed, possibly on a remote 
host, by another process (the server). The client and server 
hosts need not have the same operating system or the same 
hardware architecture. However, they do need to be able to 
reach each other via a transport protocol that is supported 
by the DCE implementations on both hosts. 

DCE RPC conforms lo a set of specifications collectiv ely 
known as the Network < 'ompuling Architecture (NCA). The 
NCA specifications define the protocols that govern the inter- 
action of clients and servers, the packet format in which 
RPC data is transmitted over the network, and the Interface 
Definition Language ( IDL) that is used to specify RPC inter- 
faces. DCE RPC is based on Version 2 of NCA. Version 1 of 
NCA was a set of architecture specifications for another 
remote procedure call facility, the Network Computing 
System (NCS), which has been in use on the HP-UX operat- 
ing system and other platforms since the late 1980s. DCE 
RPC evolved from NCS. supports the interoperation of NCS 
anil DCE applications, and offers features that assist in the 
conversion of applications from NCS to DCE. 

NCA defines two RP( ' protocols, one for use over connec- 
tion-based transports (called NCA CN RPC) and one for use 
over datagram-based transports (NCA DG RPC). The con- 
nection-based protocol relies on the underlying transport lo 
manage connections between clients and servers, whereas 
the dalagram-based protocol assumes an unreliable trans- 
port aid perforins its own connection management. A DCE 
implementation can support each of these protocols over 
several transports. HP DCE currently supports NCA connec- 
tion-based RPC over TCP/IP and NCA datagram-based RPC 
over I" DP/I P. The NCA protocols ensure that remote proce- 
dure call semantics are not affected by the underlying trans- 
port used. This characteristic of NCA. sometimes referred to 
as transport independence, is essential for the portability 
and interoperability of DCE aid DCE applications over 
many types of networks and computers. 

How RPC Applications Work. To understand how an RPC 
application works, first imagine ai ordinary nondistribured 
program consisting of a main module, which performs Vari- 
ous initialization tasks and handles user interaction, and a 
second module, which does the real work of the application 
such its interacting with a database. The main module can be 
thought of as a client of the services implemented and 
provided by the database module. In DCE terminology, a 
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module that implements a service is called a manager, and 
the set of manager routines that the client calls constitutes 
the interface between client and manager 

Fig. 2a illustrates this simple program and a representation 
of the interface between the client and the manager pieces. 
Note that Ihe modularizarion of this program demands only 
that the client and manager pieces adhere to the declared 
signature (calling syntax) of each routine in Ihe interface. 
Tliis implies that the manager module could be replaced by 
any oilier module containing routines that haw the same 
names, return lite same data type, and pass the same argu- 
ments. In an ordinary C application, routine signatures are 
typically declared in header files that get included in other 
modules. 

Now imagine thai tliis application is to be distributed so that 
the database management code executes on a minicomputer 
and Ihe user interface code executes on a graphical work- 
station. The first step in building a DCE RPC application is 
lo write an IDL interface ileliiiilion. An interface definition 
specifies the ITTD (universal unique identifier) and version 
of the interface, declares the signatures of the operations 
(routines) in the interface, and declares data types used by 
those operations (Fig. 2b). The declarations of types and 
operations in an IDL file resemble those in a C header file, 
but an IDL file contains additional information required to 
make I lie operations callable via RPC. For example, the op- 
eration declarations in an IDL file are embellished with at- 
tributes (hat specify explicitly whether the routine's argu- 
ments are inputs or outputs, so that when (he routine is 
called, arguments pass over the network only in the direc- 
tion needed. 
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Fig. 3. Flow of events when a client program calls dbjookup on the 
server. 

The next step in building a distributed application is lo com- 
pile 'he interface definition with the DCE IDL compiler 
(Fig. 2c). The IDL compiler takes the IDL file as input and 
emits three C source files as output: a client stub module, a 
server stub module, and a header file. The IDL compiler 
derives the names of the emitted files from the name of the 
IDL file. 

The client stub presents lo the application clienl module the 
same interface that the manager module did in the local case. 
For example, if Ihe manager module contained a routine 
called dbjookup. so will the client stub. Likewise, the server 
stub presents to the manager module die same interface thai 
the application client module did. Continuing the example, 
Ihe server stub calls the dbjookup routine in Ihe manager just 
as the client did ill the local case. The header file contains 
Ihe declarations needed lo compile and link the clienl and 
server programs. 

The final step in building the application is lo link these 
developer-written and IDI^-compiler-gcneraied modules into 
two programs: a client program consisting of Ihe old client 
module and the client stub and a server program made up of 
the old manager module and the server stub. (This descrip- 
lion is rat her simplified. In reality, a number of DCE library 
APIs are typically invoked by application code in both the 
clienl and server programs. ) Both programs are dynamically 
linked with the DCE shared library', which must be present 
as part of the DCE run-time environment on the clienl and 
server hosts. 

Fig. 3 describes Ihe flow of events that occur when the diem 
program calls dbjookup. The call to dbjookup is resolved in 
Ihe client stub module i . The dbjookup routine in Ihe clienl 
stub marshalls the operation's input parameters into a request 
buffer and then invokes routines in the DCE library to send 
the request lo the server host i .( )n both ihe sending and 
receiving sides. RPC code in the DCE library deals as neces- 
sary with any issues involving the underlying transport, such 
as fragmentation and window sizes. When the server program 
receives the request. D( E library code calls the dbjookup 
routine in the server stub module 3 , which uninarshalls the 
input parameters and passes them to the actual implementa- 
tion of dbjookup in Ihe application manager module ± 
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When the manager routine returns 5 . the server stub mar- 
shalls the operations output parameters and a return value 
into a response buffer and invokes DC'E library routines 10 
send I he response to the client b . Library rode on the client 
side receives the response and returns control to the client 
stub dbjookup routine 1 , which finally iiiunarshalls the out- 
puts and returns to the main client module * . 

RPC Protocols. D( IE RP1 clients and servers communicate 
over a network by exchanging messages, such as the request 
and response messages described in Fig. 3. Each message, 
called a protocol data unit I PDU), consists of up to (luce 

parts: 

A header, which contains RPC protocol control information 
An optional body, which contains data 
An optional authentication verifier, which contains data for 
use by an authentication protocol. 

The PDC itself is of course encapsulated by control informa- 
tion specific to the transport and network underlying a re- 
mote procedure call. For example, when a datagram-based 
RPC PDU is transmitted as a FDP/TP packet, it is preceded 
by UDIVIP header information. 

A few examples of information that might be carried in the 
header of a DC'E RPC PDU include: 
The version of the DCE RPC protocol in use 
The I'Dl" type (Both connection-based RPC and datagram- 
based RPC define request and response PDU types. In addi- 
tion, each RPC protocol defines several PDl" types specific 
to the protocol. For example, because datagram-based RP( ' 
implements its own connection management, it defines 
PDU types for pings and acknowledgments.) 
The UUID that identifies the interface being used 
The operation number that identifies the operation being 
called within that interface 

The IT'ID that identifies the object on which Hie operation 
is lo be performed 

A label that identities (he data representation format in 
which the PDF header and body data are encoded 
The length of the PDU body. 

Many PDU types serve only to convey protocol control infor- 
mation between a client and server and hence have no body. 
Request and response PDUs. of course, do have bodies con- 
taining the input and output parameters of the remote pro- 
cedure call. These parameters are encoded according to a 
transfer syntax identified by the data representation format 
label in the header. DCE RPC currently specifies only one 
transfer syntax, the network data representation (NDR) 
syntax. 

NDR defines the representation of each 1DL data type in a 
byte stream. For scalar types like integers and floating-point 
numbers, NDR addresses issues such as byte order and 
floating-point format. For constructed types like arrays, 
structures, and unions, NDR sets rules for flattening data 
into a byte stream. Thus, the set of input and output values 
in every remote procedure call has a byte stream represen- 
tation determined by NDR syntax. The byte stream is passed 
between client and server as the body in one or more re- 
quest and response PDUs. Table I lists the data types sup- 
ported by RPC. 



Some scalar data types have several supported formats in 
NDR. Integers, for example, may be in either big-endian 
(most significant byte first) or little-endian (least significant 
byte first ) format. For these primitive types, the format that 
governs a particular I'D! is indicated as part of the data 
representation format label in the PDF header. On any given 
hardware architecture, the DCE library will send outgoing 
data in the representations native to that architecture. If the 
receiving host has different native representations, its DCE 
library will convert incoming data (for example, by swapping 
bytes in integers) as necessary. DCE RPC thus has what may 
be called a multicanomcal approach to data representation. 
This approach tends to minimize data conversion, and in 
particular, two hosts of the same architecture can usually 
communicate without ever converting data. By contrast, if a 
data representation scheme dictates a single canonical formal 
for each scalar type, and the client and server hosts share a 
common format oilier (ban the canonical one. data will be 
convened both when sent and when received. 

The third pari of a DCE RPC PDU, the authentication veri- 
fier, is present only for authenticated remote procedure 
calls. It contains data whose format and content depend on 
the authentication protocol being used. Use of the authenti- 
cation verifier is explained further in the description of 
authenticated RPC below. 

Client/Server Binding. A key question in the design and imple- 
mentation of a DCE RPC application is. how will the client 
locate an appropriate server.' When making a remote proce- 
dure call, a client program must specify to its DCE run-time 
library the location of a server that can perform the requested 
operation. The server location incorporates an RPC protocol 
sequence (the combination of NCA protocol and network 
protocol), a network address or host name, and an endpoinl 
(for the IP protocols, the endpoint is simply a port number). 
This information is encapsulated in a structure called a bind- 
ing. A binding may also include the I I ID of the object to be 
operated on. if any, and authentication and authorization 
information, if the call is lo be authenticated) 

The RPC API supports a range of techniques for obtaining 
and manipulating bindings. Most applications either con- 
struct a textual representation of a binding (called a string 
binding) from information supplied by the user or obtain a 
binding from a name service. 

A string binding represents in a textual format the object 
UUID and server location portions of a binding. For exam- 
ple, in the string binding: 

(858c02c-e42b-l 1 ce-a344-080009357989@ncadg_ip_udp. 
192.18.59.13112001] 

the object UUID appears in the standard siring format for 
FUIDs. the ncadgjp^udp protocol sequence specifies the 
NCA DG RPC protocol over I'DP/lP, an Internet address 
identifies the server host, and a port number specifies the 
endpoint on which the server is listening. (The object UlTD 
and the endpoint are optional.) 
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Table I 

Data Types Supported in RPC 
Primitive Data Types 

Integers 

Floating-point 
numbers 

( haracters 

booleam 

bytet A type usually used in arrays or structures 

to transmit opaque data Data of type byte 
is guaranteed noi to undergo format 
conversion. 

A type tised for operations thai return no 
value, for null pointer constants, and for 
context handles. 

A type used lo store binding information 
in a format lhat is meaningful to the run- 
lime DCE library but opaque to applica- 
lions. 

A type used lo store IK E stains values. 

A set of types constructed from the byte 
primitive that support international stan- 
dards for Character and siring representa- 
tion. 



voidt 



handle tt 



error_status_tt 

International 

character 

types 



Constructed Data Types 

Structures 



I 'nions 



Enumerations 

Pipes 



Arrays 



Si rings 



Pointers 
( lontexf 

handles 



This lype is somewhat like a c union oper- 
ation, bul embeds a discriminator, which 
al run lime specifies which member Of the 
union is Stored 



An open-ended sequence of elements of 
one lype lhal is used lo transfer bulk data. 

Arrays may be one-dimensional or niullidi- 
mensional and may he of fixed size, con- 
fonnant (the array si/.e is determined at 
run lime), or varying (a subset Of the array 
Co be transmitted is determined at run 
lime). 

Strings are one-dimensional, null- 
lerminatcd arrays of characters or bytes. 



I ontexl handles are nol really distincl 
types, but pointers lo void data. They are 
specified by applying Ihe context, handle al- 
Iribule lo a parameter. A context handle 
denotes stale information thai a server 
manager will maintain on behalf of a cli- 
ent, I se of a context handle allows this 
stale lo persist across several remole pro- 
cedure ( tills from Ihe client 



String bindings are easy to generate and manipulate and are 
suitable for applications in which the user of the client pro- 
gram knows in advance the location of the desired server. 
The user can supply server location information to the client 
program interactively or as a command line argument or via a 
configuration file, and client application code can invoke 
RPC API routines lo compose a string binding and then gen- 
erate a binding handle that cam be passed lo ihe KP( ' run- 
time library. 

Siring bindings are well-suited for some RPC applications, 
but many distributed services require a more flexible anil 
transparent way of establishing bindings. DCE RPC provides 
an applic ation interface, the RPC name servic e independent 
( NSIj API. through whic h servers and clients can export and 
import binding information to and from a name service. The 
use of a name service to store binding information insulates 
clients from knowledge of where objects and servers reside. 
The client lias only to Specify an object and an interface and 
then use the name service to look up the location of an 
appropriate server. Thus, the relocation or replication of a 
server can be made transparent to clients. 

As its name suggests, the RPC NSI interface is independent 
of any particular name service. Thus, applications coded to 
this Interface will potentially he portable across DCE imple- 
mentations incorporating a variety of name services. In the 
current HP DCE implementation. DCE CDS underlies the 
RPC NSI interface, so thai ihe generic RPC name service 
routines invoke corresponding DCE CDS routines. In princi- 
ple, another name service such as X/Open Federated Naming 
(see artic le on page 28) could supersede ( 'IIS in the DCE 
run-time environment, and existing RPC applications would 
continue to work. 

DCE security, which is desc ribed in the article on page 41, is 
mi example of a service thai takes advantage of both RPC 
binding methods. The security client code- in Ihe DCE run- 
time library can bind to a security server cither through RPC 
name sen ice calls or through a siring binding generated 
from a configuration file on the clieni hosi. The configuration 
file solves a boots! nipping problem by making Ihe securily 
service localahlc even when CDS is unavailable. 

Authenticated RPC. The ability to perform authenticated RPl 
is crucial lo the usefulness of DCE in Ihe real world, where 
Ihe integrity and privacy of dala often must be assured even 
when the dala is transmitted over physically insecure net- 
works. DCE supports several levels of authenticated RPGso 
lhal applications will incur only Ihe performance overhead 
necessitated by Ihe desired degree of proleclion. These 
levels include: 
> None. No protection is performed 

• Connection. An encryption handshake occ urs on the fust 
remole procedure call between Ihe clieni and Ihe server, 
exchanging authenticated identities Tor clieni and server. 

i ( all. In addition lo connection-level prolec lion, Ihe integrity 
of Ihe firs! PDl ' of each request and response is verified. 

■ Packet. In addition to call-level proleclion, replay and mis- 
ordering detection is applied to each PDC. ensuring lhal all 
dala received is from the expected sender. 
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• Packet Integrity. In addition to packet-level protection, the 
integrity of every PDU is verified. This level can be thought 
of as protection against tampering. 

• Packet Privacy. In addition to packet -integrity-level protec- 
tion, all remote procedure call parameters are encrypted. 
This level can he though! of as protection against both eaves- 
dropping and tampering. The privacy protection level is not 
available in all DCE implementat ions because of restrictions 
on the export of encryption technology from the I'niled 
States. 

When data integrity is protected, the senile! i ampules a 
checksum of the data, encrypts the checksum, and inserts 
the encrypted checksum in the authentication-verifier por- 
tion of the RPC PDl* for verification by the receiver. When 
data privacy is protected, the sender encrypts the actual 
parameters in the RPC PDU body, and the receiver decrypts 
them. 

The authenticated RPC facility is intended to accommodate 
more than one authentication and authorization service. A 
server program registers with the DGE run-time library the 
authentication protocol it supports. A client specifies an 
authentication protocol, an authorization protocol, and a 
protection level in its binding. When the server receives a 
request, application code in the manager can extract authen- 
tication and authorization information from the request. IIP 
DGE currently supports only the shared-secret authentica- 
tion protocol implemented by l)CK security. 

Distributed Time Service 

The distributed lime service, or DTS, is a distributed service 
that synchronizes the clocks of all hosts in a cell with each 
other and, optionally, with an external time source. In a typi- 
cal cell configuration, a few hosts (perhaps three) run a DTS 
server daemon, and all other hosts run a DTS client daemon 
called a DTS clerk. One of the DTS server hosts may also run 
a daemon called a time provider which obtains time from an 
external source. DTS clerks and servers communicate via 
RPC and also rely on CDS and security services for naming 
and authentication. 

Clock synchronization is essential for I he operation of a DCE 
cell. The various methods used in several DCE technologies 
to cache or replicate data, for example, require that clocks 
agree closely. 

In addition to the daemons that synchronize clocks, DTS 
includes a library of programming interfaces that allow ap- 
plications to generate and manipulate lime values In binary 
format or in any of several standard textual formats. DTS 
associates an estimated inaccuracy with every time value, 
so a time value can also be treated as an interval that is 
likely to include the correct time. Internally. DTS always 
keeps time values in the Cniversal Coordinated Time (UTC) 
standard governed by the International Time Bureau. The 
DTS API allows applications to display time Values in local 
time zones. 

DTS Clerks. Most hosts in a DCE cell run a DTS clerk. A clerk 
periodically (at a randomized interval of roughly ten minutes | 
obtains time values from DTS serv ers in the cell. The clerk 
then reconciles these results to compute a single value and 
inaccuracy that it applies to the local host. This computation 



takes into account the inaccuracy of each server and an 
estimate of the time lost to processing and communications. 
If one DTS server has a faulty clock that disagrees sharply 
with the others, the clerks will ignore that value, preventing 
the faulty clock from influencing time throughout the cell. 
Usually, the time intervals from the servers (time values plus 
or minus inaccuracies) intersect, and the computed lime lies 
within this intersection (see Fig. 4). 

The clerk adjusts time on the local host in such a way that 
the clock is corrected gradually and continues to advance 
iiionoionieally. It is especially important to avoid a sudden 
backward collection because many software systems, in- 
cluding some components of DCE, depend on the monoton- 
icity of the clock. In most computers, a hardware oscillator 
generates an interrupt at some fixed interval, and this inter- 
rupt, called a lick, causes the operating system to advance a 
softw r are register by some increment. Slight inaccuracies in 
oscillators cause clocks to drift relative to each other. To 
adjust time, rather than write Ihe computed correct time 
directly to the clock register, Ihe DTS clerk changes Ihe in- 
crement by which the register advances with each tick. In 
effect, the software clock rate is increased or decreased to 
bring the local host into agreement with the servers. 

DTS Servers. DTS servers can be configured in two ways: 
• If a DTS time provider is running on one of the server hosts, 
the DTS servers on all oilier hosts synchronize with the DTS 
server on thai host (roughly every two minutes). Thus, time 
obtained by the time provider from an external source is 
propagated to the DTS servers in the cell. 
■ If there is no DTS time provider in the cell, the DTS servers 
synchronize with each other (roughly every two minutes). 
This process is similar to Ihe one used by clerks, except dial 
each DTS server also uses its own time as one of Ihe input 
values. 

Externa] time sources can include telephone and radio ser- 
vices, such as those operated in the I'niled Stales by ihe 
National Institute of Standards and Technology and various 
satellite services. DTS can also use an Internet network time 
protocol (XTP) server as an external time source. Though 
DTS and NTP cannot both be allowed to control the clock 
on any one client host, the DTS NTP time provider can be 
used to synchronize a set of DTS-conl rolled hosts with a set 
of NTP-controiled hosts. 
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DTS servers and time providers attempt to compensate for 
processing and communications delays when they obtain 
time values, just as the DTS clerks do. 

Distributed File Service 

As the UNIX operating system has spread from standalone 
computers to networked workstations, the need to combine 
file systems in heterogeneous collections of computers has 
grown. A few solutions have evolved to meet this need, 
including the Network File System (NFS) from Sun Micro- 
systems and the Andrew File System (AFS ) from Transarc 
Corporation- The Distributed File Service (DFS) is a succes- 
sor to AFS that is integrated into DCE. 

DFS adds a global filespace to the DCE namespace (see the 
article on page 23 for a description of DCE naming). File- 
sets, the logical tutits of file system manipulation in DFS. are 
mounted within the DFS filespace for access by DFS clients. 
1 >FS cleanly separates the logical and physical aspects of 
file serv ice, so thai a user can always access a file in the 
DFS filespac e by the same name, regardless of w here the 
file or the user physically resides. All DBS file system opera- 
tions comply with the I'OSIX 1003.1 specifications for file 
access semantics. A token-based file access protocol en- 
sures that readers and writers always see the latest changes 
to a file. 

DFS is a distributed service w hose major components are a 
cache manager that runs on DFS client hosts, a fileset server 
and file expoiter that run on DFS server hosts, and a fileset 
location server thai can inn on any DCE host. Communica- 
tion among lliese components is via RPC; some DFS pro- 
cesses run in I lie operating system kernel and make use of a 
special iu-kernel implementation of the datagram-based RPC 
protocol. Fig. "> illustrates the relationships between lliese 
processes and the logical roles that B host can assume. In an 
actual DFS deployment, one host may play one, two, or all 
three of these roles. 

( Ithcr DFS son ware in the IIP DCE product includes a DFS- 
lo-NFS gateway w hich exports the DFS filespace to NFS, 
providing secure access to DFS tiles from hosts outside a 
DCE cell, an update service that keeps files in synchroniza- 
tion between hosts, a basic- overseer server that monitors 
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Fig. 6. The relationship between DFS aggregates unci filesets 

DFS daemons on each DFS hosl and supports various remote 
administrative operations, and other administrative utilities. 

Server support for some DFS features is dependent on the 
level of functionality provided by ihe local file system soil- 
ware on the server host. For the purposes of this article, a 
local file system can be classified as either a traditional 
I "NIX file system or an extended file system thai offers mote 
advanced functionality. DFS server software can support ihe 
full range of DFS features only if the underlying file- system 
provides extended file system functionality, HP-UX file sys- 
tems currently provide only I "NIX file system functionality, 
so HP I X DFS server hosts do nol support the DFS features 
that depend on extended file system functionality. If DFS is 
deployed across a heterogeneous set of platforms, DFS 
server machines from other vendors may have file systems 
thai do allow full DFS support. When ac cessing files from 
such a machine, an Hl'-l 'X DFS client host can lake- advan- 
tage of the entire DFS feature set. 

Aggregates and Filesets. The DFS filespace is ;i hierarchy of 
directories and files thai forms a single logical subtree of the 
DCE namespace. The root of Ihe DFS filespace in ;i cell is 
the directory whose global name Is /.../<cell-name>/fs. This 
directory can also be accessed from within Ihe cell by the 
local name A: /fs or by the special prefix /:. The directories 
and files in the DFS filespace can reside physically on many 
different DFS server hosts in the D< E cell. Two types of 
DFS resources reside on DFS server hosts: aggregates and 
filesets (see Fig. <>) 

An aggregate is the DFS reference to the physical entity 
from which one or more filesets are created From the per- 
spective of Ihe local operating system, this entity is a logical 

disk managed by local file system software. For example, an 

aggregate could refer lo a logical volume or to a physical 
partition on a disk. 

A filesel is a hierarchy of directories and files that are stored 
in an aggregate. An extended file system aggregate can store 
several extended file system filesets, whereas a UNIX file 
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system aggregate can store only one UNIX file system file- 
set. Each fileset lias a name (assigned by an administrator) 
and a number (generated automatically) that are unique in 
the DGE cell. A DFS client uses the fileset name to locate 
the fileset, and tints the files it contains, by looking tip the 
name in the fileset location database. 

Many UFS features involve manipulations of filesets. The 
operations an administrator can perform on a fileset include: 
Mounting it in the filespace so that UFS clients can see its 
files 

Racking il up 

Setting its quota so that when several filesets reside in one 
aggregate, the disk space in the aggregate is not dispropor- 
tionately consumed by one fileset 

Moving it to another aggregate to balance the load among 
aggregates and UFS server hosts 
Replicating it for performance and reliability. 

The last three of these operations are supported only by 
extended file system aggregates. 

Mounting a fileset in the UFS filespace makes the tree of 
directories and files in the fileset visible to UFS clients. The 
fileset is mounted at an entry in the filespace. called the 
mount point, which then names the root directory of the 
fileset. For example, a fileset containing the home directory 
for the user Joe might be named users.joe. An administrator 
might decide to mount the home directories for all users 
under one directory' in the UFS filespace, such as /.../<cell- 
name>/fs/users. The administrator would issue a command to 
mount users.joe at, say, /.../<cell-name>/fs/users/joe. Joe could 
then use this pathname to access his home directory from 
anywhere. UFS mount points are permanently recorded in 
the file system as special symbolic links and. unlike UNIX 
file system mount points, need not be recreated each time a 
host boots. 

A UFS fileset can also be locally mounted, by the UNIX 
mount command in the directory hierarchy of the local host. 
For example, the users.joe fileset could be mounted at /users/ 
joe. A file in a UFS fileset thus can be accessed by several 
names: a local pathname specific to the local host (like 
/users/joe/rnail.txt), a pathname relative to the local cell (like 
/:/users/joe/mail.txt). and a global pathname (like /.../<cell-name>/ 
fs/users/joe/mail.txt ). UFS guarantees that operations on the file 
adhere to POSIX semantics, regardless of which way the file 
is accessed. 

DFS Client Components. Each host that accesses the UFS file- 
space runs a set of UFS client processes that execute in the 
kernel, which are collectively called the cache manager. The 
cache manager interacts with the client host kernel, which 
makes file requests, and with file exporters, which service 
file requests. It also maintains a local cache of files that have 
been accessed. The cache can reside either on disk or in 
memory. 

When a file in the UFS filespace is referenced, the virtual file 
system layer of the kernel invokes the UFS cache manager 
to handle the reference. The cache manager checks to see 
whether the local cache can satisfy the requested mode of 
access to the requested file. If not, it consults the fileset 
location server to locate the file exporter that manages the 
requested file and then forwards the request to the file 



exporter. All data returned by file exporters is cached to 
reduce load on the servers and on the network. 

The interactions of the cache manager with fileset location 
servers, file exporters, and the local cache are entirely hid- 
den from the operating system on the client host. To the 
user, accessing a DFS file is no different from accessing a 
file in a local file system. 

DFS Server Components. Each DFS server host rims a set of 
UFS processes that provide access to its filesets and files. 

The fileset server process responds to fileset management 
requests from administrative clients for filesets residing on 
I lie UFS serv er host. The RPC interface escorted by the file- 
set server includes operations to create and delete filesets, 
dump and restore them, and get and set status information. 
Fileset servers cooperate with each other, with fileset loca- 
tion servers, and with file exporters to implement operations 
such as fileset movement and fileset replication. 

The file exporter process responds to file access requests 
from clients for files residing on the UFS server host. The 
file exporter is responsible for reading and writing data to 
the file and for managing attributes of the file such as its 
modification time. 

DFS Fileset Location Server. DFS keeps information about die 
current state of all filesets in the fileset location database. 
This replicated database tracks the aggregate and the UFS 
server host at which each fileset resides. A set of daemons 
called fileset location servers maintains the fileset location 
database. Fileset location servers can ran on any hosts in a 
cell but are typically configured to run on a subset of the 
UFS server hosts. 

If a UFS client encounters a UFS mount point while resolving 
a pathname, it contacts a fileset location server to obtain the 
current location of the fileset mounted at that mount point. 
Given the fileset 's host and aggregate, the UFS client can 
then issue a file access request to the correct file exporter. 
Because clients look up fileset locations dynamically, a 
fileset can be moved or replicated without users and appli- 
cations being aware of the change. UFS fileset servers auto- 
matically update the fileset location database whenever 
necessary. 

Underlying the fileset location database is a data replication 
subsystem that implements quorum and voting algorithms to 
maintain the consistency of fileset location data among all 
fileset location servers, even in the event of hardware or 
network failure. A UFS client can thus get current, correct 
data from any fileset location server. 

DFS Token Management 

One of the major benefits Offered by UFS is its provision of 
single-site file system semantics. With respect to the file 
system, programs running on different machines behave in 
general as though they are all miming on the same machine. 
All clients see a consistent view of the file system. If a pro- 
cess modifies a file in any way. that change is immediately 
reflected in any operations performed on that file by other 
processes. To ensure this behavior, each UFS server host 
must know how clients are using its files. The UFS client 
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and server processes exchange this knowledge and synchro- 
nize their actions by exchanging tokens. A token is a guaran- 
tee from a server to a client, granting that client permission 
to use a file from the server in a particular way. Tokens are 
handled by a DFS subsystem called the token manager, which 
interacts closely with the cache manager on the client side 
ami the file exporter on the server side. 

Tlie following information is encapsulated in a token: 
Token Type. A bit mask lhal encodes one or more of the 
values listed in Table II. The token type describes the rights 
granted to a client by the token. 

File ID. A unique low-level name for a file. It consists of a 
DCE cell identifier, a DFS fileset identifier, a file identifier, 
and a version number. 

Byte Range. For data and lock token types, the byte range 
indicates the portion of the file to which the token applies, 

A DFS client cannot perform any operation on a file unless it 
possesses all the tokens required for that operation. For 
example, ihe statd system call requires a read status token, 
the read!) system call requires both read status and read data 
tokens . and the openl) system call requires an open token. In 
some cases, the required token is already being held and the 
operation can proceed immediately. However, in other cases 
the client machine must contact the token manager on the 
server host to obtain the necessary tokens. 

When the token manager on a DFS server host receives a 
request for a token from a client, it first decides whether the 
requested token can be legally granted, based on a set of 
token compatibility tides. For example, several clients can 
have read-data tokens for a file, but if one client has a wriie- 
data token for a portion of a file, then no other clients can 
have a read-data or wrile-dala token that overlaps thai 
portion. If Ihe requested token does not conflict with any 
outstanding tokens, il is granted immediately. Otherwise, the 
token manager first revokes any conflicting Tokens I'rortl 
other Clients before granting the requested token. 

The rules by which tokens are expired, returned, or revoked 
are also important for correct semantics and optimal perfor- 
mance. A token has a finite lifetime, which a client can re- 
quest to extend ff necessary. By default, tokens expire after 
two hows, which is short enough that a token usually will 
tune out before the server has to revoke it, but long enough 
that the client usually will not need to refresh it. Data or 
status tokens generally remain With a client until they either 
time QUI or are revoked. Before returning a write token, of 
course, a client must first send back to Ihe server any modi- 
fications that it made (0 the file while it possessed the token. 

The file-version information in a token helps clients use 
cached data efficiently. When a client is granted a token by a 
server for a file that remains in its cache from a previous 
access, the client uses the file-version information to deter- 
mine whether the cached data needs to be obtained again. 

Conclusion 

The Distributed Computing Environment (DCE) integrates 
technologies for threads, remote procedure calls, security. 



Table II 

Token Types Used by the Token Manager 

Token Type Rights Granted to a Client 

Read Status Entitles a client to read the attributes of 
a file and cache them locally 

Write Status Entitles a client to modify the attributes 
of a file 

Read Data Entitles a client to read some portion of 

a file designated by an associated byte 
range and to cache it locally 

Write Data Entitles a client to modify some portion 

of a file designated by an associated 
byte range 

Read and Indicates that the client has an advisory 

Write Lock lock on some portions of a file desig- 

nated by an associated byte range 

Open Indicates that a process on that client 

has a file open 

Delete Technically a type of open token which 

Ls used during the deletion of files 

Whole Volume A special token that applies to the file- 
Token set as a whole and is used to coordinate 
the interaction between ordinary opera- 
tions on single files and operations on 
entire filesets, such as the movement of 
a fileset from one server to another. 

naming, time synchronization, and remote file access. DCE 
eases the development and execut ion of secure client/server 
applications and ensures the portability and interoperability 
of these applications across many kinds of computers and 
networks. 
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Adopting DCE Technology for 
Developing Client/Server Applications 



HP's information technology community has adopted DCE as the 
infrastructure for developing client/server information technology 
applications. The team developing the DCE service has discovered that 
putting an infrastructure like DCE in place in a legacy environment is muie 
than just technology and architecture. 

by Paul Lloyd and Samuel D. Horowitz 



Many companies art- 1 navigating I he path to open systems. 
Vendors, including Hewlett-Packard, claim that companies 
can receive significant benefits by adopting open system 
client/server approaches for implementing information tech- 
nology solutions. While the benefits may be attractive, the 
array of architecture and technology choices is bewildering. 

Hewlett-Packard's information technology group has adopted 
the Open Software Foundation's Distributed Computing 
Environment (OSF DCE) as a recommended technology for 
the implementation of client/server applications within IIP. 
The adoption of a technology, or even an architecture, is not 
sufficient lo ensure that Ihe benefits of the client/server 
model are realized. In fact, once the architecture and tech- 
nology are chosen, Ihe real journey is.just beginning. This 
paper discusses Ihe issues that led IIP lo shift toward open 
systems for information technology client/server applications, 
the rationale for choosing DCE as a key technology, and the 
elements of a new infrastructure built to provide Ihe neces- 
sary services required to realize Ihe benefits of open systems. 

HP's Legacy Environment 

Until veiy recently, HP's legacy environment included multi- 
ple mainframes and over UJOll IIP :(000 computers operating 
in more than 7"> data centers located around the world. 

Business transactions were processed at places called sites, 
which were major HP installations including manufacturing, 
sales, and administrative centers. Each site had a local IIP 
3000 computer system. Most applications were written in 
COBOL and made extensive use of HP's Turbolmage data- 
base management system and \Tlus/3()00 routines for termi- 
nal screen management. These tools were used because 
they made the inosl effective use of the HP 3000 computer 
system. At periodic intervals, batch jobs on the IIP .100(1 sys- 
tems would create transaction files for transmission to the 
mainframes. Other batch jobs processed files received from 
Ihe mainframe. A proprietary store-and-forward system 
provided Ihe link between the interactive IIP 3000s and the 
batch-oriented mainframes. Fig. 1 illustrates this legacy 
architecture. 

This architecture gave each site access to its own data, but 
only its own data. Once a transaction was generated and 



sent lo the mainframe, interaction with oilier production 
systems meant that response was indeterminate. For exam- 
ple, system users would have lo check repeatedly to deter- 
mine if a purchase order thai had been entered was ac- 
cepted by the factory and scheduled for production. This 
acknowledgment could lake from hours to days depending 
on the complexity of Ihe order and Ihe number of HP divi- 
sions supplying content. In addition, processing and data 
communication delays anyw here in the company could 
Impact the response time for the transaction, but Ihe user 
had no way of finding the bottleneck. Further problems 
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Fig. 1 HP's legacy environment for information technology. 
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were found during massive dala center consolidations that 
have taken place over the past few years. 

The architecture for I IP legacy applications yielded a large 
number of applications, each of which required large main- 
tenance and support staffs. Many applications were custom- 
ized to address the j>eculiarities of various sites. This eon- 
trilMited to the support problem. As proc essing power and 
network bandwidth grew, the customized versions of stan- 
ilard applications made consolidation difficult. In some 
cases, support c osts ac tually grew. 

New applications were both expensive and took a long time 
to develop, integrate, and deploy. They made little use of 
previously written code, nor did they share data or other 
resources effectively. This resulted in a great deal of repli- 
cated data w ithin the company. As the environment contin- 
ued to evolve and new applications came online to address 
business needs, users found themselves having to manage a 
mull it tide of passwords for a large number of systems. From 
a security standpoint, each password was transmitted 
multiple times daily over the network, and host-based login 
services provided the foundation lor all dala security. 

Movement toward Change 

Several years ago. HP realized the benefits that could be 
achieved through open systems client/server architectures. 
The single biggest driver for the change was a desire to re- 
duce business implementation time, which is Ihe time from 
when a business need is identified to Ihe lime when a pro- 
duction system is in place to address the need. Oilier drivers 
in- hided the need for greater cost -effect iveness of the infor- 
n ation technology (IT) organization, and ihe need to reduce 
• perational and administrative costs. An informal ion tech- 
nology steering group determined that the widespread use 
of a client/server architect ure would enable a reduction in 
business Implementation lime and provide increased organi- 
sational effectiveness and reduced costs. 

A group of IT leaders representing multiple IIP organizations 
formed a lask force to develop a client/server archil eel lire 
for use within IIP. Some of Ihe factors Ihe lask force consid- 
ered when choosing Ihe best client/Server technology to 
adopi for our environmenl included 

• Training optimization and the experience of the current 
staff 

• Concurrent processing in a distributed environment 

• Enhancing security for confidential and critical dala 

• Moving application servers wilh minimal impact on clients 

• Providing interoperability with existing client/server 
applications and lools 

• Enhancing the portability of applications across 
architectures 

• Operating across ihe IIP internet on an enterprise-wide 
basis. 

The evaluation of these fac tors by Ihe lask force resulted i" 
a recommendation that ihe Open Software Foundation's 
Distributed Computing Environment be adopted as a stan- 
dard technology for the implementation of client/server 
applications within IIP. 



DCE and the Evaluation Factors 

0GB excels in the area of optimizing the training and experi- 
ence of the current staff. One problem faced by early adopt- 
ers of client/server computing was that no one could agree 
on the definition of what was a client and what was a server. 
This led to a plethora of home-grown and purchased solu- 
tions that did little to leverage the nature of the HP comput- 
ing environment 

The definitions of client and server within DCE are consistent 
and tangible. A client refers to a program that c alls a remote 
procedure. A server refers to a program that executes the 
procedure. There is no confusion with hardware or clients 
and servers on the same system or even a single program 
being both a client and server. The definitions are entirely 
consistent. In addition, these definitions fit perfectly within 
the context of HP's client/server application model. 

DCE uses the remote procedure call ( RPC) mechanism for 
client/server communication. This too is beneficial for pro- 
grammers because it |S an extension of a concept tliat every 
programmer knows and understands: how to write and exe- 
cute procedures (or subroutines). In DCE, RPCs behave the 
same as local procedures. They are still distinct, modular 
collections of functionality with well-defined parameters 
that behave in a "black-box" fashion: send them the required 
parameters, and they reply in a predefined and predictable 
manner. Further, RPC is unobtrusive in that it hides the com- 
plexity of the distributed environment. 

With RPCs, application programmers do not need to learn 
Ihe intricacies of data networking or the particulars of a 
variety of application programming interfaces (APIs) to 
implement distributed applications effectively. Unlike other 
technologies. RPCs ensure that the operational c onsider- 
ations of network programming are both hidden and auto 
malic. Lastly, the DCE APIs required to establish the client/ 
server environment can be easily abstracted lo hide even 

more from ihe application developer wilh the further benefit 
of contributing to consistency in the environment 

I sing these concepts, and Ihe lools described later, several 
Of "in application teams have experienced reduced imple- 
mentation limes in spite of the need for training in new 
technologies. 

New issues and opportunities arise with the movement to 
client/server architectures, one of these opportunities is the 
ability to gain more effec tive use of computing resources on 
the network. Through the implementation of a threads facil- 
ity, DCE gives application developers the ability lo have a 
clienl call multiple servers simultaneously. In this way, an 
individual user executing a clienl program can invoke Ihe 
parallel processing power of many servers. On the other 
end. the threads technology also allows servers to respond 
to multiple clients by processing each request within its own 
I bread. This entails significantly less overhead than Ihe cre- 
ation and destruction process employed by many alternative 
technologies I hat require a unique server process per client. 
I HE threads are briefly described in Ihe article on page 'i. 
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[>< E also incorporates a time service API to provide a con- 
sistent network-wide view of time. This service addresses 
the issues created when applications require time stamps to 
be reconciled across geographic boundaries or between 
systems. 

Security is another area that raises both issues and opportu- 
nities. IIP has traditionally used host password security and 
the security features inherent in the operating system to 
protect data ami applications. If a user gained access to an 
application, then the user was presumed to have authority 
to execute any transaction performed by the application. In 
recent years, some application teams have supplemented 
host security with features prov ided by relational database 
management systems (RDBMS), but these too are usually 
limited in their flexibility. For example, a user that may have 
the ability to change a record when executing an authorized 
transaction should be prohibited from doing so with a data- 
base maintenance utility. Such discrimination is beyond the 
capability of most relational database management systems 
and requires added attention to system administration. 

DGE extends the concept of security to the application it- 
self. The principles of DCE security are authentication and 
authorization. DCE provides three services to enable the 
ultimate authorization of actions within a server. The regis- 
try service is a database used to keep information about 
users, groups, systems, and other principals* that can have 
an identity within the DCE security framework. The authen- 
tication service, based on the widely respected Kerberos 
technology from the Massachusetts Institute of Technology, 
is used to allow principals to authenticate themselves. The 
privilege service supplies the privilege attributes for a prin- 
cipal. These attributes are used by an access control list 
(ACL) manager within the body of a server to make autho- 
rization decisions. Using an ACL manager, server authoriza- 
tion decisions can be as granular as business needs dictate. 
Back doors, such as maintenance utilities or rogue pro- 
grams, are not possible because users have no access to the 
systems on which critical data is stored. This makes the 
properly authenticated and authorized transaction the only 
vehicle by which a user can affect the database. Security 
and ACLs are also described in the articles on pages 41 and 
49, respectively. 

In addition to authentication and authorization. DCE pro- 
vides features to protect both the integrity and privacy of 
data transmitted over a network. These features can be in- 
voked by clients or servers when the sensitivity of business 
data dictates that such precautions are prudent. 

Another challenge of the environment is change. I lata cen- 
ters are consolidated and moved, and hardware within the 
centers is replaced on a regular basis. 

DCE provides a flexible, scalable directory service that Can 
be used to apply human readable names to objects such as 
servers. Servers record their binding information at startup. 
Clients then locate servers wherever they may be. Multiple 
directory types permit great flexibility for the application 
developer. For example, the corporate telephone directory 
may have replicated instances of the server at many loca- 
tions. Should one server fail, a client can automatically bind 

A principal can be either a human user 01 an active object Imachme. tile, process, etc ). 



to another. In the case of an online transaction processing 
system, the one and only server can be found reliably by a 
client even if it has been moved temporarily after a disaster. 
Both of these cases can be accomplished with no changes to 
the client or the users system configuration. DCE's global 
directory serv ices are described in the article on page 2:1. 

Hewlett -Packard was a significant contributor to the tech- 
nology suite that makes up the OSF DCE definition. One of 
the most important contributions was the RPC mechanism. 

DCE's RPC is a compatible superset of the Network Com 
puling System (NCS) from what was once Apollo Computer. 
The principles upon which the two solutions are based re- 
main the same. They include platform independence and 
platform unawareness. 

DCE platform independence comes from the fact that it runs 
on all computing platforms in common use within HP's IT 
environment: HP 30(10 computers. HP HOOD workstations. 
Intel-based Windows" 3.1, and Windows NT. Platform un- 
awareness comes from the fact that application program- 
mers only need to concent themselves with the platform 
they are working on. Thus, when a developer codes a client, 
there is no need for the developer to be concerned with 
what platform the server will run on. Conversely, the server 
developer does not need to know what platform the client is 
using. Thus, an application client running on a desktop PC 
can send a byte string or pointer to a server running on a 
PA-RISC platform even though the data representations on 
the two systems are different. Fig. 2 shows a typical configu- 
ration of some of the components in HP's DCE client/server 
environment. 

RPC provides the added benefit of inleropciating with die its 
and servers already implemented using NCS. This provide, a 
transition for applications to the more robust world of DCE. 

HP operates one of the world's largest private Internet 
Protocol (IP) networks. The final criterion used by the task 
force was that the client/server technology chosen must 
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Fig. 2 'lite new client/server environment for information technology 
operations. 
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operate on HP's internet in an enterprise-wide fashion. DCE 
was designed to operate in the IP environment in a scale 
well above the size required for HP's enterprise. 

The task force concluded that the adoption of DCE as a 
standard technology would enable some significant benefits 
including: 

Replacement of batch store-and-forward applications with 
OLTP 

Encapsulation of legacy code and data into servers that can 
be accessed by Gi l clients 

Implementation of elientfserver applications with minimum 
training 

Abstraction of much, if not all. of the infrastructure so that 
application teams can concentrate on the business aspects 
of applications 

Implementation of enterprise- wide robust security 
Movement of servers between systems without impacting 
the client or the configuration of the client's host system. 

Building HP's DCE Infrastructure 

Because of the scope of DCE and the scale of problems that 
DCE addresses, careful plaiuiing is required w hen deciding 
how to deploy DCE. We found that the best approach is to 
start with the customers. As a group responsible for deliver- 
ing DCE to HP's information technology community, we 
defined several categories of customers: 
End users. These are the people who interactively use appli- 
cations. 

Application development teams. These are the people re- 
sponsible for designing and constructing applications in 
response to some stated business need. 
Application administrators. These are the people who ad- 
minister and support business applications in production. 

Our group, which is the client/server tools group for HP's 
corporate network services department, has a long history 
of providing application data transfer solutions to each of 
these types of customers. The lessons gained from this ex- 
perience are simple, even intuitive. End users want technol- 
ogy to be as absolutely invisible as possible, application de- 
velopment teams want to focus on their specific business 
problems, and application administrators want tools and sup 
port. In other words, whenever users must rely on technol- 
ogy in provide a solution, I hey want to be consumers of the 
technology and like all consumers, they demand certain 
things from a technology supplier such as: 
A higher level of abstract ion than is usually provided by the 

technology 

The ability to make necessary, simplifying assumptions 
A consistent level of service in all cases. 

(liven these requirements, HP has chosen to deploy DCE in 
the form of an Infrastructure. This infrastructure is known 
as the HP DCE service. In corporate network services par- 
lance a service is an Infrastructure with some specific prop 
erties. The prime reason for the term service is that the 
entire effort is focused upon meeting the needs of our cus- 
tomers, the people of Hewlett-Packard. The term service has 

connotations of careful planning, standardization, published 

guidelines, and customer satisfaction. Il does not have con- 
notations of central control, corporate mandate, or arbitrari- 
ness. Finally, a service is a process as much as il is a tangible 

solution, and ii recognises that as the sophistication of its 



customers and their business problems grow- with time, so 
too will their expectations. 

Associated with every service is a value proposition. The 
value proposition formally defines the customers, the bene- 
fits provided to the customers, and the cost of these benefits. 

Our experience designing and constructing a DCE infra- 
structure can be summarized very succinctly: 

• The irurastructure must accommodate diversity. 

• The infrastructure must provide consistency. 

• The infrastructure must grow experience. 

Accommodating Diversity 

Identifying div ersity is a crucial aspect of customer aware- 
ness. The customers of a distributed computing solution 
come from all parts of the organization with distinct require- 
ments. We identified four categories that the DCE service 
must accommodate. 

The first category is netw ork performance. Customers of the 
DCE service are, by definition, users of HP's IP network 
infrastructure. Because of differences in networking tech- 
nology, customers of the HP internet can realize a difference 
in both bandwidth and transit delay exceeding two orders of 
magnitude. Given the request/reply nature of the RPC proto- 
cols, this differenc e will also be reflected in every DCE oper- 
ation. The lesson of diis category is that the infrastructure 
imisi not make assumptions regarding the motion of 

packets. 

The second category is application scope. Many business 
applications are truly enterprise- wide in scope in that there 
are lens of thousands of clients and massive, dynamic rcpli- 
caiion of the application servers. Many business applications 
are only deployed to a single group or department where 
there are perhaps a few dozen clients and only a single ap- 
plication server is required. 

The third category is the different types of application users. 
Some users use data entry applications in which a small 
number of transactions are constantly performed to add or 
modify data. Other users use data query applications to per- 
form a modest number transactions to read data. Other ap- 
plications provide decision-support serv ices, which typically 
allovv users to perform ad hoc- transactions that read data. 
Finally, some applications serve tioninteractrwe c lients that 
typically invoke large numbers of transact ions that read, 
add. and modify dala. 

The fourth category is the geographic- dispersal of the enter- 
prise. HP does business in several countries all over the 
world. What this means is that nighttime or weekend service 
outages cannot lie tolerated. 

We learned from Ibis kind of analysis that enterprise-Wide is 
a one-dimensional term, and real enterprises are not one- 
dimensional. We have addled the terms enterprise-deep and 
enterprise-broad. Enterprise-deep addresses the diversity of 
application users because il acknow ledges that a successful 
infrastructure will accommodate every type of user. Enter- 
prise I in iai I addresses the diversity of network performance 
and application scope by acknowledging that all business 
processing miisl be accommodated. In addition, today's 
business processes often cross company boundaries. In 



© Copr. 1949-1998 Hewlett-Packard Co. 



December MOB Hewlett -PaekaHl Journal 19 



these situations, it also necessary to he enterprise- 

independent 

HP's DCE service accommodates diversity in several key- 
ways. Tlie policies and guidelines lor the assignment of leg- 
ist ry and namespace ( l)( IE cell directory service) objects 
support massive replication of application servers. This 
allows IK K to he used as a foundation for truly enterprise- 
Wide computing. The support model spans all organizations 
and all lime zones, and no customers are ever treated as 
second class. The subscription model allows all customers 
to gain access quickly and easily. A suhseriplion-hascd ser- 
vice provides convenient focal points for satisfying service 
requests. Finally, policies anil guidelines delegate control to 
the appropriate level. Thus, since IK E is a distributed com- 
puting solution, its administration must also be distributed. 

Consistency 

Providing consistency is a crucial aspect of customer satis- 
faction. Despite their diversity, all customers are Consumers 
of the same technology They all demand a complete and 
comprehensive solution. Furthermore, the biggest return on 
IT investment comes from building on a consistent founda- 
tion that encourages resource sharing and leverages Off 
other infrastructures. As in the case Of diversity, the best 
place to start is with the customers. 

Knd users hav e specific requirements regarding consistency. 
Since they must sit in front of and interact with the applica- 
tions, end users are best served when all applications based 
on DCE offer a consistent interface with respect to IX'E. A 
Consistent interface offers equivalent dialog boxes for per- 
forming the standard tasks of DCE login and credential 
refresh. A consistent interface also offers an equivalent 
mechanism of dialog boxes or configuration files for server 
binding and server rebinding. Sine"' I x 'E is an enabling tech- 
nology, end users are best served when they can access a 
varietv nl IK K applications using their unique, enleiprise- 
wide identity. Gaining credentials should be a side effect of 
being an employee of the organization, not a side effect of 
being a user of application X. Finally, there are standard 
tasks, such as password administration, that all end users 
must pei'fOUU and are best Served when they all have access 

to a standard set of tools. 

Application development teams have specific requirements 
regarding consistency. Since application development learns 
are responsible for incorporating DCE functionality into 
applications as pail of a business solution, they are best 
served when they can make the necessary simplifying as- 
sumptions. Application teams rlo not want the burden of 
acquiring and administering the core servers that provide 
the DCE security service and the DCE cell directory service. 
Removing this burden is especially important for teams who 
develop applications that must scale to serve the entire 

enterprise- 
Application development teams also benefit from the ability 
to use tools that abstract the native DCE APIs. These tools 
dramatically reduce implementation time, and if they are 
Standard and consistent, training is leveraged across appli- 
cation team boundaries ;is well as across applications. 



Finally, application development teams benefit from the 
ability to leverage from established best practices and estab- 
lished experts. Despite the common misconception that best 
practices and experts are ;ui attempt to constrain teams, 
experience has shown their advantages. ( 'ode reuse and 
resource sharing improve because similarity can be lever- 
aged. Also, business implementation time is less because the 
need for retraining is reduced, and application quality 
increases because teams refine, improve, and reuse their 
skills. 

Application administrators have specific requirements re- 
garding consistency. As is the case with application develop- 
ment teams, administrators are best served when they can 
make the necessary simplifying assumptions. If an end user 
approaches the administrator to gain access, the administra- 
tor should be able to ask the end user's principal name and 
then perform (he appropriate application-specific ACL ad- 
ministration and group management The nonapplicat ion- 
specific tasks of requesting an end user principal and 
machine principal and obtaining properly licensed copies of 
the 1 II E software should be lefl to the end user. The benefit 
to the application administrator is vastly reduced workload 
because the administrator only deals wilh the application. In 
addition, registry objects such as groups ;ue leveraged 
across application boundaries. 

Application administrators also benefit from the ability to 
leverage the best practices and standard tools. If DCE appli- 
cations use DCE objects such as regis! ry groups and name- 
space entries in a consistent fashion, retraining is minimized 
and a large cause of administrative errors is reduced. 

Hewlett-Packard's I )( E service provides consistency in 
many ways. Cell boundary decisions are weighted in favor 
of larger cells to promote genuine enterprise-wide comput- 
ing. Tasks associated with DCE cell administration have 
been abstracted into high-level tools based upon the ser- 
vice's subscription model. These tools automate and hide 
specific, low-level DCE tasks. For example, the task that 
corresponds to an application subscription creates princi- 
pals, groups, and accounts for the application's servers, 
creates namespace entries for the application, and modifies 
all associated access control lists. The benefit of Ibis 
abstraction is the consistency that it ensures because the 
actual registry and namespace objects are generated and 
administered in a standard, documented manner. 

Growing Experience 

Growing experience, which means making both application 
developers and application users successful, is a crucial 
aspect of realizing the business benefits of DCE. dearly, an 
infrastructure that is not used is useless. Growing experience 
is a two-step process that never ends. The first step is to 
identify barriers, and the second step is to remove these 
baitiers by any means necessary. Such means include, but 
are not limited to. the development and deployment of cus- 
tom tools, the abstraction of DCE tasks to better suit exist- 
ing business practices, and exploitation of the fact that DCE 
is already one of its own best customers. The need for cus- 
tom tools is by no means a negative reflection on DCE. but 
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simply aii acceptance of the fact that no single solution can 
do everything for everybody. Abstraction is simply a way to 
make DCE fit the business rather than forcing the business 
to fit DTE. Taking advantage of DCE means understanding 
that everything in DCE is basically a DCE object accessed 
by a client through an interface and protected by an ACL 

Application developers face a variety of barriers. The most 
traumatic barrier stems from the large number of new tech- 
nologies directed towards development teams. Keep in mind 
tltat in most organizations, new technology really means 
new to the organization. In Hewlett-Packard, most IT appli- 
cation teams are new to writing distributed applications 
using DCE s client/server split or RPC paradigm. Our distrib- 
uted applications have traditionally been based on file trans- 
fers or message passing. The learning curve for all of the 
technologies associated with DCE is nontrivial. especially 
when the development tools associated With the technologies 
are still evolving. The consequence to application developers 
is that creating the first DCE application With oui-of-ilie-hox 
DCE. even an evaluation application, is usually a difficult 
task. The risk is that IT application teams will not consider 
using DCE. 

Application developers also lace barriers when testing or 
deploying applications. The richness of DCE offers the de- 
velopers an often bew ildering variety of choices such as 
different ways to take advantage of the namespace or differ- 
ent methods of allocating registry objects to take advantage 
of DCE security, Without guidelines, established practices, 
and assistance some teams will simply try anything and then 
fail. Reports of these failures usually travel faster and wider 
I ban reports of teams I hat succeed. 

HP's DCE service removes these barriers in three key ways. 
First, the service provides a DCE development library I lull 
abstracts the native DCE APIs into Iwo very high-level API 
routines thai include one call for the client and one call for 
the server. Second, the service offers a custom version of 
the OSF DCE programmer's class, which focuses on HP's IT 
environment. Third, the service offers consultants who can 
help other entities start DCE projects. A typical consulting 
vendue involves the creation of Inlerface Definition 
Language (1DL)I files, a skeleton server that takes full 
advantage of security and the namespace, and a skeleton 
clienl 1 1 ml can bind lo I he server. After Ibis is all done the 
application team only has to add the application code 
between the curly braces. The best part of DCE is thai il 
allows one lo distribute an application without worrying 
about how lo do il. 

Application administrators face barriers because for DCE 
applications, there will be DCE related lasks thai Ibey niiisl 
perforin either directly or indirectly in a production eiiviron- 
ment. All hough production-quality DCE applications do not 
require much attention, there are still issues thai can arise. 
For example, there is the occasional administration of Mid- 
points and namespace entries in server failure cases, the 
occasional administration of server keytah files, and most of 
all, the administration of the applications ACLs used to con- 
trol authorization. The oul-of-lhe-box DCE tools are eiiiuber- 
si niie and error-prone, and worsl ofall, 1 1 n-y are i;iiii\ |m - 

t IDL is a language similar lo C lhai allows developers lo specify the interlaces thai lie client 
ami server applications together 



level and require a fairly detailed knowledge of DCE con- 
cepts. The risk is that DCE applications can acquire an un- 
deserved reputation as being costly and difficult to support 
in production. 

HP's DCE service removes these barriers by providing cus- 
tom OSF/Motif tools to ease these DCE related tasks. Also, 
the published guidelines and best practices that bring con- 
sistency to DCE applications can help to grow experience 
by reducing the need lo retrain. 

System administrators face barriers because of the complex- 
ity of one of the most common tasks in a growing, maturing 
DCE cell. Since DCE regards each physical machine as a 
principal with iis own authenticated identity, configuration 
niiisl be done on each machine when adding it to the cell. 
The oui-of-the-box tools have two significant problems. 
First, they require coordination by the system administrator 
for root access. Second, if configuration is done across the 
network, both the rool password and the DCE celLadmm 
password are exposed. These are unacceptable security 
holes especially for a system that is intended to serve as a 
foundation for secure distributed applications. In addition, 
many machines already run NCS applications, and these 
applications must not be impacted by the migration to DCE. 
As a result; installation and configuration are tedious and 
potentially insecure. The risk is that deploying DCE through- 
out the enterprise will be viewed as slow and expensive. 

Hewlett-Packard's DCE service removes these barriers in 
three key ways. First, we have developed a scheme that 
allows a machine to be remotely and securely added to a 
cell. In particular, this scheme does not expose the operat- 
ing system or DCE passwords across the network. It also 
doesn't require any effort on the part of the system adminis- 
trator Other than to install an KM X 1 HleSet Second, we are 

integrating the DCE client software into a common operat 

ing environment for machines thai run the III'IX operating 
system. Third, we provide a PC-DCEtt license server to ease 
the distribution of PC-DCE. 

End users face a variely of potential barriers. Although it is 
the job of the application developer lo shield D( 'E from end 
users, they will slill be aware of iheir DCE principal. Thus, 
end users should have minimal training on obtaining and 
refreshing their network credentials as well as managing 
their principal. ( >ut-of-the-btMS DCE does not include a 
standalone password management tOOl, and users must ac- 
tually run rgy_editand modify their account Also, integrated 
login SplUttonS in which the operating system and DCE log- 
ins are combined are still evolving (see the article on page 
34). The risk is thai deploying DCE applications to large 

numbers of end users can be slow, lediotis, and expensive, 
and t he end users who are exposed to loo much DCE be- 
cause of poorly const rucied applications may assume that 
all DCE applications are difficult to use. 

HP's l)( 'E service removes these barriers in two key ways. 
First, we provide tools on both the IIP-I X operating system 
and the PC to ease password ailininist ration. Second, the 
service's subscription model provides a simple focal point 
for requesting and obtaining a DCE principal. 

PC DCE is an implementation nl DCE thai runs in an MS Windows environment 
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The final barrier to growing experience conies from two 
groups of people. The firs! group believes thai client/server 
is really jusl remote SQL, and the second group believes that 
client/Server just means the motion of bits over the network. 
Remote SQL is certainly a fine solution for some business 
problems. However, it is important to remember that vendor 
luck-in. clienl-side awareness ofdalaba.se schema, network 
performance on the WAN, and the usual lack of network 
security could be problems in dealing with remote SQL. Al- 
though DI E does move bits over the network, and oilier 
approaches such as message passing using sockets may be 
an adequate solution lor many business problems, the issues 
of WAN performance, architecture differences, code sharing 
difficulties, code maintenance difficulties, and the usual lack 
of network security could be problems in other approaches. 
When making technical decisions, being dogmatic is usually 
the first step towards being unsuccessful. The goal is not to 
dictate or even to impress, but to educate and promote a 
community in which decisions are marie objectively. 

Hewlett-Packard's DCE service addresses these barriers in 
two ways. First, we offer classes on all aspects of DCE and 
its use. Second, service subscribers can access all published 
information using Worldwide Web browsers. 

( ionctusion 

Perhaps the best way to get a clear perspective of HP's DCE 
service is via analogy with other well-known infrastructures. 
Consider customers of a WAN. Everyone wants access and a 
consistent service model such as enterprise-wide IP Connec- 
tivity. Consider the technology that is used to build a WAN. 
Now consider a successful WAN infrastructure. It is much 
more than the technology (i.e.. routers, bridges, etc.) used to 
build it, it is a also a distributed creature that requires dis- 
tributed administration and coordinated planning and guid- 
ance. Furthermore, there IS no distinction between a test 
network anil a production network. The network is simply 
an infrastructure that supports all phases of the software 
lifecycle. 



Another valuable analogy is the interstate highway system in 
the I "nited States. In the 10'iUs automotive technology 
boomed and the resulting cost structures allowed many 
people to own a car. This produced a fundamental change in 
American society because of the freedom, power, and 
movement of goods and services the automobile permitted. 
Perhaps the biggest contributing factor was the interstate 
highway system. The interstate highway system really 
wasn't about automotive technology. It was about use and 
access. Distributed applications are the same. The focus 
shouldn't be on distributed computing technology but on use 
and access. 

DCE is a powerful and impressive collection of software 
technology. It offers attractive solutions to the kinds of busi- 
ness problems that most large organizations must address. 
Our experience has demonstrated the following: 
It is OK to experiment. 

It is important to allow a few key people to become 

industry-level experts. These are the people who should he 

responsible for service management. 

DCE should not be managed by regulatory practices. 

It is Imperative tO abstract anything if the result better fits 

the business needs anil business practices. 

Activities should not be done in secret or kept secret. 

A service such as D< E is as much a continual process as it 

is a tangible solution. 

HP UX 9.* and 100 loi HP 900D Series 100 and 800 computers are X/Open Company UNIX 93 
branded products 

UNIX is a registered trademark in the United States and other countries, licensed exclusively 
through X/0nen Company I imited 

X/Open is a registered trademark and the X device is a trademark ol X/Open Company Limitefl 
in the UK and other countries 

Open Software Foundation, OS? and 0SI7Mutil are trademarks ol the Open Software Founda- 
lion in Ihe U S and ollmr countries 

Windows and MS Windows are U S teyisteied trademaiks or Microsoft Corporation 
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DCE Directory Services 



The DCE directory services provide access for applications and users to a 
federation of naming systems at the global, enterprise, and application 
levels. 



by Michael M. Kong and David Truong 



The director.' services uf the Open Software Foundation's 
Distributed Computing Environment (DCE) enable distrib- 
uted applications to use a variety of naming systems, both 
within and outside a DCE cell. Naming systems make it 
possible to give an object a textual name that is easier for 
humans to use — easier to read, pronounce, type, remember, 
and intuit — than an identifier such as a DCE universal unique 
identifier ( LT'ID). Information about Lite locations of objects 
can be stored in naming systems so that users can access an 
Object by name, with no a priori knowledge of its location. 

DCE provides three directory services: 
The Global Directory Service (GDS) is the DCE implementa- 
tion of the CCITT (International Telegraph and Telephone 
Consultative Committee) 1988 X.500 international standard. 
GDS is a distributed, replicated directory service that man- 
ages a global namespace (be names anywhere in the world 
The Cell Directory Service (CDS) is a distributed, replicated 
directory service that manages names within a DCE cell. 
The Global Directory Agent (GDA) is a daemon that uses 
global name services to help applications access names in 
remote cells. GDA interacts with either X.500 services such 
as GDS or Internet Domain Name System (DNS) services 
such as the Berkeley Internet Name Domain (HIND) name 
server, named. 

Through these services. DCE applications can access several 
Interconnected namespaces, including X.500, DNS. CDS, the 
DCE security namespace (see article, page 41 ). and the DCE 
Distributed l-'ilc Service (DPS) filespace (see article, page 6) 

The DCE Namespace 

The DCE namespace is a federation of namespaces at three 
levels: global namespaces, an enterprise- namespace, and 
application namespaces. A DCE name can span one. two. or 
all I luce of these levels. GDS and BIND name servers provide 
X.500 and DNS global namespaces in which the names of 
DCE cells are stored. Within each DCE cell, CDS provides 
an enterprise namespace, and the names of CDS objects in 
that namespace are relative to that cell. At the application 
level, DCE subsystems including DCE security and DPS 
define their own namespaces. 

DCE names are hierarchical names consisting of a series of 
COmpQnentB delimited by the /character. The first component 
of a DCE name is one of three prefixes denoting the root of 
a namespace: 

/-.. is the global root. A name that begins with / ... is called a 
global iKimr. 



is the rout uf the local cell This prefix is shorthand for 
/.../<local-cell-name>. Names that begin with /.: are called Im-ni 

nanus. 

• /: is the root of the DFS filespace. This prefix, shorthand for 
I.Jfs. makes DFS filenames easier to use. 

Within the local DCE cell, local and global names for an 
object are equivalent and interchangeable. However, when a 
user references a local name, the resolution of the name is 
relative to whatever cell the user is in. Hence, to access an 
object in a remote cell, a user must refer to the object by its 
global name. 

A DCE cell has a global name that may be either an X.500 
name stored in GDS or a DNS name stored in a BIND data- 
base. For example, a cell at HP's Cupertino site could have 
the GDS global name /.../c=us/o=hp/ou=cupertino. In X.500 syntax, 
the components of a name are separated by the / character, 
and each component describes an attribute of the object. 
The component o=hp, for instance, signifies the organization 
named HP. The DNS global name /.../cssl.cell.ch.hp. com might 
name a cell in HP's Chelmsford systems software lab (CSSL). 
As this example shows, a DNS name is a single component 
of a DCE name but is itself a compound name. DNS names 
are made up of names in the hierarchical DNS namespace, 
separated by periods and ordered righl-lo-left from the DNS 
root. 

i tlijects in a cell have names that are composed Of tin- cell 
name, a CDS name, and possibly a name from an application 
namespace. Some objects, such as RPC servers, are named 
directly in the CDS namespace; their names consist of a cell 
name plus a CDS name. Other objects, such as DFS files or 
DCE security principals, are managed by a service lhal im- 
plements ,ui application namespace. The name for such an 
object is formed by concatenating a cell name, a CDS name 
for the root of the application namespace, and an applica- 
tion name relative to that root. For example: 
> [f the HP Chelmsford systems software lab cell is running 
an RPC server from the Acme Database Company, that 
server might be registered under the name /.. ,/cssl. cell ch hp com/ 
acme/acme_server (see Fig. 1 ). Within the CSSL cell, /.:/acme/ 
acme_server would be an equivalent name for the Server. 

■ If the HP CSSL cell includes a principal named Nijinsky, lhal 
principal would have the global name /.. ,/cssl. cell. ch.hp.com/ 
sec/pnncipal/ni|inksy (see Pig. 2) and the local name/, /sec/pnnci- 
pal/nijinksy. 

■ If the DFS filespace in the IIP Cupertino cell contains a file 
called /users/sergey/mail/igor. lhal file would have the global 
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/. . /cssl cell hp com/acme/acme server 



/, , ./cous/o=hp/ou=cupenino/1s/useia/sflfgB¥/mail/igor 
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Global Obiecl Nome 
Fig. 1. A] » K global name for a server. 

name /.../c=us/a=hp/ou=cupenino/fs/users/sergev/mail/igor (see 
Fig. 3). Within Cite Cypeitino cell. the names /../fs/users/sergey/ 
mail/igor and / /users/sergey/mail/lgor would be equivalent names 
for t he file. 

Directory Service Interfaces 

DCE offers two sets of programming interfaces to directory 
services. The RPC Name Service Independent ( NSI i API is a 
generic naming interface provided by DCE RFC. 'Hie X/Open " 
Directory Service (XDS) and X/Open OSI Abstract Data 
Manipulation (X< >M ) APIs are interfaces based on < (TIT 
X.500 standards. 

Transparently to an application, the DCE directory services 
interact with each other as necessary to resolve names. 
Fig. 1 illustrates some of the interrelationships between 
I hese services. 

When a DCE application passes a name to the KPC NSI API. 
CDS client software (in the DCE run-time library and in CDS 
client daemons) uses DCE RPC to contact a CDS server 
either in the local cell or in a remote cell to look up the name. 
Names in the local cell are passed directly to a CDS server 
in the cell. Names in a remote cell are passed to a GDA dae- 
mon, which performs a lookup in X.500 or DNS. depending 
on the syntax of the cell n;uue. to obtain the location and 
identity of a CDS server in the remote cell. The CDS client 
software then uses this information to contact the remote 
CDS server. 

When an application passes a name to the XDS/XOM APIs, 
the XDS code in the DCE run-time library resolves the name 
according to its syntax. If the name consists purely of com- 
ponents such as c-us and o=hp, the XDS library passes the 
name to the GDS client code, which contacts the CDS server 
to look up the name. If any portion of the name is uoi in 
GDS syntax, the name is passed to the CDS client code and 
resolved in the same way as names passed through the RPC 
NSI API. 

GDS Directory Structure 

The GDS directory is a collection of information about ob- 
jects that exist in the world. Information about objects is 
stored in a database called a directory information base. A 
directory information base contains an entry that completely 

/ /cssl.cell hp.com/sec/principal/nijinskv 
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describes each object and may also contain an alias entry 
that provides an alternative name for an obiecl entry. 

An entry in the directory information base consists of a set 
of attributes, each of w hich stores informal ion about the 
object to which the entry refers. An attribute is made up of 
an attribute type and one or more attribute values. For ex- 
ample, an entry for a person might include attributes whose 
attribute types are surname, common name, postal address, 
and telephone number. Attributes that have more than one 
value are called multivalued attributes. A person with more 
than one telephone number would have a multivalued tele- 
phone number attribute. 

Each entry can belong to one or more object classes. An 
object class of an entry restricts the permitted attributes for 
that entry. The mandatory and optional attributes of entries 
in an object class are determined by object class rules, and 
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Fig. 4. Inl errelatidnshilM between DCE directory services. The 
application program interfaces (APIs) are the DCE remote proce- 
dure call name service independent API (RPC NSI API) and the X/' 
Open Directory Service (XDS) and X/Open OSI Abstract Data Manip- 
ulation (XOM ) APIs. GDS is lite DCE Global Directory Service and 
CDS is the DCE Cell Directory Service. (IDA is the DCE Global Di- 
rectory Agent X.500 is an international standard implemented by 
the DCE GDS. DNS is the Internet Domain Name System. The Berke- 
ley Internet Name Domain (BIND) is an implementation of DNS. 
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these rules are part of a schema For example, an entry rep- 
resenting an organization must contain an attribute called 
Organization-Name, which has the name of the organization as 
its value. An entry can contain optional attributes that de- 
scribe the organization: the state or locality in which the 
orgaiuzation resides, the postal address of the organization, 
and so on. As a general rule, all entries must contain the 
Object Class attribute, which contains the list of object classes 
to w hich the entry belongs. If an entry belongs to more than 
one object class, all object classes must be listed in this 
attribute. 

As discussed above, attribute types and object classes have 
human-readable names that are meaningful and unique, but 
they are not used in the protocols; an object identifier Ls 
used instead. An object identifier is a hierarchical number 
assigned by a registration authority. The possible values of 
object identifiers are defined in a tree. The standards com- 
mittees ISO and CC'ITT control the top of the tree and define 
portions of this tree. These standards committees delegate 
the remaining portions to other organizations so that each 
object class, attribute type, and attribute syntax has a uni<|iip 
object identifier. For example, the object identifier of I lie 
country object class is 2.5,6.2, which can also be written more 
verbosely as: 

joint-iso-ccitl(2}modules{5}object classes{6)country(2}. 
X.500 Naming Concepts 

Information in the directory information base is organized in 
a hierarchical struct lire called a directory iiiformatioii tree. 
A hierarchical path, called a distinguished name, exists 
from the root of the tree to any entry in the directory infor- 
mation base. Bach entry in the directory information base 
imiisi have a name that uniquely describes that entry. For 
example, the employee (entry) David has the distinguished 



name C=US/0=hp/OU=ripinri/CN=Davirj. where C denotes the coun- 
try. 0 the organization. OU the organization unit, and CN the 
common name. 

The distinguished name is a collection of attribute type and 
attribute value pairs called relative distinguished names. 
From the example above, C (country) is an attribute type 
and US (United States) is an attribute value. 

Alternative names are supported in the directory information 
tree tltrough special entries called alias entries. An alias 
entry is a leaf entry in the director," information tree tliat 
points to another name. Alias entries do not contain any 
attributes other than their distinguished attributes because 
they have no subordinate entries. 

GDS Components 

As shown in Fig. 5. GDS is made up of four main com- 
ponents: 

• Directory Use? Agent ( Dl'A). This process is the users 
representative to the direc tory service. The user can be a 
person or an application. 

• Director,- System Agent (DSA). This process controls and 
manages access to directory information. 

• DUA Cache. This process keeps a cache of information 
obtained from the directory DSAs. One DL'A cache runs on 
each client machine and is used by all the users on that 
machine. The Dl'A cache contains copies of recently 
accessed object entries and information about DSAs. 

• Directory Infonnation Base. This is where GDS stores 
information. 

The Dl'A and DSA communicate by using the directory 
access protocol. DSAs use the directory system protocol to 
communicate with each other. 
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Since directory in formal ion is distributed over several 
DSAs, a DUA first directs any queries to a specific DSA. If 
this DSA does not have the information, there are two stan- 
dard request methods that the DUA can use. Tie first method 
is referral — the USA addressed returns the query to the DUA 
together with a reference indicating the other DSAs that 
have the information. Chaining is the second request 
method — the addressed DSA passes on the query directly to 
another DSA via the directory system protocol. 

CDS Directory Structure 

Every DCE cell must have at least one CDS server. The CDS 
servers in a cell collectively maintain a cell namespace, or- 
ganized into a hierarchical directory structure. As mentioned 
above, the prefix / is shorthand for the global name of the 
cell and hence denotes the root of the cell namespace. 

A CDS name is simply a series of directory names followed 
by an entry name. The directory names are ordered left-to- 
rigbl from the cell root and are separated by die / character. 
For example, in the name /.:/acme/acme_server, the directory 
acme is a child of the cell root and the object acme_server is an 
entry in acme. 

In a cell that contains more than one CDS server, CDS direc- 
tories can be replicated, with each replica of a directory 
managed by a different CDS server. Among die replicas in a 
set, only one. the master replica, is modifiable; all other rep- 
licas are read-only. Replication increases the availability and 
reliability of CDS service and can ease recovery from hard- 
ware or network failure. 

A CDS directory can contain three types of entries: 
Object entries contain information about objects in the cell. 
An object can be a host, a user, a server, a device, or any 
other resource that has a CDS name. 
Soft links provide alternate names for Objects, directories, 
or other soft links. 

Child pointers are pointers to the directories contained by a 
parent directory. A child pointer is created when a new dircc- 
toiy is created and is used by CDS to locate replicas of that 
directory when resolv ing the directory's name. Child pointers 
are created only by CDS itself, not by applications. 

Like CDS. CDS stores information about named objects by 
associating attributes with names. Object entries might have 
attributes to store the object's UUID. its location, its access 
control list (ACL), the time it was created, and the lime it 
was last updated. A soft link has an attribute to store the 
name of the objecl to which the link points. 

Two special classes of CDS objecl entries warrant particular 
mention: 

RPC server entries store information about servers, including 
their location and the objects they manage, in the CDS data- 
base. Servers register this binding information, and clients 
look it up. via the RI'C NS1 interface. 
Junctions enable a service that Implements its own name- 
space to splice diat namespace into the DGE namespace. A 
junction is somewhat analogous if) a mounl point in a 
UNIX" file system; the junction enir.v si ores binding infor- 
mation for a service and becomes the root for the name- 
space managed by lhat service. The CDS entry /.:/sec, for 
example, is the junction for the DCE security service. Appli- 
cations can use names such as /.:/sec/principal/stravinsky to 



identify principals in the security registry and to obtain 
bindings to a security server. Similarly. /.:/fs is the junction 
for DPS, and /.:/hosts/<host-name>/config is the junction for the 
configuration sen ices prov ided on each host by the DCE 
host daemon, deed. 

CDS Components 

CDS is a distributed service based on a client-server model. 
Fig. 6 illustrates the soft ware components that implement 
this service. 

All CDS directory data is stored in databases called clearing- 
hfruses, which are managed by CDS server daemons. The 
server daemon responds to requests from CDS clients for 
lookups in or updates to the database. When an RPC server 
invokes an RPC NSI API routine to export binding informa- 
tion to the namespace, for example, this routine triggers a 
CDS update operation. Similarly, when an RPC client im- 
ports bindings from the namespace, a CDS lookup operation 
is executed. Each CDS server keeps an image of its clearing- 
house in memory and writes the clearinghouse periodically 
to disk. 

A cell often includes more than one CDS server, each with 
its own clearinghouse. Running several CDS servers in one 
cell allows administrators to replicate CDS directories. If a 
directory is replicated, one clearinghouse stores the master 
replica of the directory, and other clearinghouses store read- 
only replicas. Clients can perforin lookups from any replica 
but can perform updates only to the master replica. After a 
CDS entry is updated in the master replica of its directory, 
die CDS server that manages the master replica propagates 
the update to all CDS servers dial manage read-only replicas. 
Replication improves responsiveness to clients by distribut- 
ing work among several servers and ensures the availability 
of CDS service if a server machine fails or the network fails. 

The architeclure of CDS insulates applications from direct 
communication with CDS servers. To add, delete, or modify 
CDS data, applications call APIs such as the RPC NSI rou- 
tines in the DCE run-time library. CDS client code in the 
library interacts with a daemon on the local host called the 
CDS ailrertiser, which uses RI'C to communicate as neces- 
sary with CDS servers. A CDS advertiser runs on every host 
in a DCE cell. (In many DCE implementations, several CDS 
client daemons execute on each host: one CDS advertiser 
and a number of CDS clerks. In the IIP DCE/9000 product, a 
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single CDS advertiser process subsumes all advertiser and 
clerk tasks. I To increase client performance, reduce server 
load, and reduce network traffic, each advertiser saves the 
results of its lookups in a cache. Frequently accessed data 
can l>e retrieved locally from the cache rather than via RFC 
from a server. The advertiser writes the cache to disk peri- 
odically, so cached data persists ihnmgh reboots of the CDS 
client host. 

Conclusion 

DCE provides a three-level naming system and two naming 
APIs. 

Names of cells are stored in a global namespace managed by 
a DNS server such as named or by an X.&00 server such as 
the DCE Global Directory Service (GDS). The Global Direc- 
tory Agent (GDA) oversees resolution of global cell names. 

The cell namespace consists of two levels: the enterprise 
namespacp managed by the DCE Cell Directory Service 
(CDS) and application namespaces such as those managed 
by DCE security and the DCE Distributed File Service 
(DFS). The roots of application namespaces are named by 
CDS junctions. 

DCE offers two naming APIs, The RPC NSI interface is used 
by servers to register their names and locations in CDS and 
by clients to look up names and get back binding informa- 
tion. The XDS/XOM API can access names and their associ- 
ated attributes in GDS and CDS. 



The DCE name services have some limitations that X/Open's 
Federated Naming specification attempts to solve (see 
article, page 28). The RPC NSI API is a specialized interface 
that manages only RPC binding handle information: it can- 
not read or manipulate other attributes associated with a 
name. Many programmers find the XDS/XOM API cumber- 
some; this interface is also difficult to layer over other exist- 
ing naming APIs. The RPC NSI API and the XDS/XOM API 
do not offer a way to create or delete directories program- 
matically. so an application that needs to create directories 
currently must use an internal CDS interface. The CDS and 
GDS pro tO C Ofa are complicated and not very general. New 
naming services that are introduced are unlikely to use 
either or these protocols or the XDS API. Finally. CDS does 
not support an easy, general way to create and resolve 
through junctions to application namespaces. 
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X/Open Federated Naming 



The X/Open Federated Naming (XFN) specification defines uniform 
naming interfaces for accessing a variety of naming systems. XFN 
specifies a syntax for composite names, which are names that span 
multiple naming systems, and provides operations to join existing naming 
systems together into a relatively seamless naming federation. 

by Elizabeth A. Martin 



Naming of objects is ;i fundamental need in a computing 
system. A naming service maps human-readable names to 
internal location information that programs use to access 
the named objects. Current distributed computing environ- 
ments that lake advantage of large computer networks pre- 
sent new problems and requirements for the naming service. 

Heterogeneous naming systems are a reality. Unlike the 
naming service in a single-host system, the naming service 
in a distributed system is usually not a monolithic compo- 
nent but consists of various naming systems embedded in 
different pieces of the system. The naming systems in the 
Open Software Foundation (OSF) Distributed Computing 
Environment (DCE. see article, page 6) include the X.500 
directory service. 1 the DCE Cell Directory Service (CDS), 2 
and the DCE Distributed File System (DFS. see page 6). The 
DCE security service ( see article, page 41 ) and the DCE dae- 
mon (see article, page 6) also support namespaces. A typical 
DCE installation will have applications that have their own 
naming systems, such as databases, email, desktops, and 
spreadsheets. 

These different naming systems have arisen in part because 
they meet different requirements. The DCE security server 
uses special and somewhat inconvenient measures to pro- 
tect the keys of principals in the system. DCE CDS directo- 
ries are replicated but a desktop is not. A spreadsheet 
names fine-grained objects (its cells) which present unique 
scaling problems. New naming systems will continue to 
appear, particularly in applications. 

Up to now. there has been no basic and consistent naming 
interface. Each naming system has its own AIM. so applica- 
tion programmers must write custom software for each 
naming system that their applications use. When applica- 
tions are ported to different systems, they must be modified 
to use that systems naming interfaces. As new naming sys- 
tems are introduced, applications that need to use them 
must be extended. 

There has also been no first-class, generic support for com- 
posite names. A few distributed systems support composite 
names — names that span multiple naming systems. This 
support is limited and specialized. The DCE name 
/.../ch. hp.com/sec/principal/jsmith is a composite name, ch.hp.com is 
resolved in the Internet DNS 1 - ' namespace, sec is resolved in 
the DCE CDS namespace, and principal/jsmith is resolved in 
the security service's namespace. In DCE only the security, 
file system, and DCE daemon namespaces can be accessed 



through composite names. UNIX* rep uses composite names 
in a different way from DCE. For example. a|ax:/tisr/jsmith/nam- 
ing/memo.txt is an rep name with two components: ajax is a 
host name and /usr/jsmith/naming/memo.txt names a file on ajax. 
DCE and rep use their own syntaxes and conventions for 
their names. 

Another area of inconsistency between naming systems is 
their policies for how the namespace is structured. Many 
systems have very little policy and what policy there is has 
evolved in a haphazard way. Application writers who use the 
namespace to advertise their services must follow different 
conventions for the various environments in which their 
programs will run or they must invent their own policies for 
using the namespace. Administrators who configure a site 
are also faced with confusing, inconsistent, or no policy for 
how to use the namespace. End users need intuitive ways of 
finding and naming objects. 

Overview of X/Open Federated Naming (XFN) 

Several vendors of distributed computing systems realized 
that they shared these naming problems. Engineers from 
Digital. HP, IBM, OSF. SNI, and Sunsoft started work on a 
naming specification in June 1993'. In March 1994 version 1 
of the Federated Naming Specification 71 went to X/Open* for 
fast -track review. The specification achieved preliminary 
status in July 1994. The multivendor team continued to work 
on extensions to the specification and on validating it before 
it became part of the X/Open Common Application Environ- 
ment (CAE) in 1995. 

The XFN specification defines application programming 
interfaces (APIs) and corresponding remote procedure call 
( RPG) interfaces. XFN specifies a naming syntax for com- 
posite names and provides operations to join different nam- 
ing systems together into a relativ ely seamless naming fed- 
eration. XFN also specifies some naming policy. 

Fig. 1 illustrates an XFN configuration. The XFN API is lay- 
ered over a framework into which different context imple- 
mentations are inserted. A specific context implementation 
is required for each naming system in a federal ion. A con- 
text implementation maps XFN operations into operations 
that are native to its naming system. For example, the NIS+' 1 
context implementation maps operations in the XFN API to 
corresponding operations in the NIS+ API. A naming system's 
software below the context implementation is not changed. 



28 Dei ember 1995 Hct len-Pai-kard Journal 

© Copr. 1949-1998 Hewlett-Packard Co. 



XFN Client System 



»FNLitM»t>,»t«nw«otk 



DNS 3 H>S ■ COS 

Implnwnlrtign ■ baplrnwnuiion ■ IraplramUlioii ■ Implcmeatjli 





ImemMDNS I XMODtlA ■ CDS Clerk NIS. Client NOS Client 




Mme4 XUXH.rvet COS Servtir NIS* Server I NOS Server 




XFN Ptotocol- 
Eiporting 
Nameserver 



Fig. 1. XFN riitiflguratioii using 
client context implementations. 
A program socking internal toot 
Boa information fur a huitian- 
rcarlable name passes the name 
to the Xf N API. The name is 
liroken apart ami proc essed by 
the appropriate naming systems, 
and the desired liiratinn informa- 
tion is returned by the naming 
system servers (bottom row). 



To join a federation, a naming system must simply provide 
its specific context implementation. 

In Fig. 1 the client-side software for five naming systems 
runs on the XFN client system. In addition, an XFN client 
module thai imports an XFN protocol is on diis system. The 
XFN client module may do caching and other typical naming 
client jobs. Each naming client on the system uses its native 
protocol to communicate with its server, 

Definitions 

In this section and hereafter in this article, paragraphs in 
quotation marks are taken directly from the X/Open Feder- 
ated Naming Specification. ' 

"Every name is generated hy a set of syntaclic rules called a 
naming convention. An atomic name is an indivisible com- 
ponent of a name, as defined by the naming convenlion. 
A COtnpoimd name represents a sequence of one or more 
atomic names composed according to the naming conven- 
tion." 

Case sensitivity, the choice of escape, quote, and delimiter 
characters, and the order of atomic names in a compound 
name are common features of a naming convention. 

"In I NIX pathnames, atomic names are ordered left to right, 
and are delimited by slash (/) characters. The t "NIX path- 
name usr/local/bin is a compound name representing the- se- 
i|tience of atomic names, use local, and bin In names from the 
Internet DNS, al otitic names are ordered from light to left, 
ami are delimited by dot (.) characters. Thus, the DNS name 
sales Wiz.com is a compound name representing the sequence 
of atomic names com, Wiz. sales." 

"The reference of an object contains one or more communi- 
cation cuilpoints (addresses). The association of an atomic 
name with an object reference is called a binding, A context 
is an object whose stale is a set of bindings. Every context 
has an associated naming convenlion." 



A UNIX directory is a type of context. An atomic name in 
one context can be bound to a reference to another naming 
context object, called asiil/context. 

"A nan/inn system is a connected set of contexts of the 
same type (having the same naming convention) and provid- 
ing the same set of operations with identical semantics. In 
the I NIX operating system, for example, the set of directo- 
ries in a given file system (;utd the naming operations on 
directories) constitute a naming system. A naming seroia 
is the service offered by a naming system. Il is accessed 
using its interface. A namespace is the set of all names in a 
naming system." 

The XFN API 

XFN defines uniform naming interfaces thai support basic 
naming funclionalily. As Illustrated in Fig. 1. the XFN inter- 
lace is layered over specific naming sen ices' APIs. The de- 
tails of the underlying naming system are hidden from Ihe 
application, Applications that use the XFN AIM can access a 
variety of current and fulure naming systems without 
modification. 

The operations in ihe XFN interface range from simple to 
complex. Simple naming systems arc not expected to sup- 
port Ihe more complicated operations, but the funclionalily 
offered by sophisticated naming systems can still be accessed 
via Ihe XFN API. 

flic XFN base context interface includes operations to bind 
an atomic name in a conlexi to an XFN" reference and to 
unbind a name. Other operations in the XFN base context 
interface look up a name and return its reference, look up a 
link, list all names and bindings in a context, and create a 
subcontexl. 

XFN supports ihe notion of attributes (or properties) associ- 
ated with a name. Attributes can be used to provide summary 
characteristics about Ihe object being named. For example. 
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a printer might be named /.../Wiz. corn/eng/os/service /prntrl. The 
name prntrl would be bound to an XFN reference thai con- 
tains ilie address of the server for that printer. Attributes 
could also be associated with the name prntrl that describe 
its type (LaserJet, inkjet. etc.) and the formats it supports. 

Attributes are accessed through the XFN attribute interface, 
which includes operations to set, modify, and get attributes 
associated with a name in a context. An attribute consists of 
an identifier, a syntax, and one or more values. Operations 
to search for names whose attribute values match a filter 
expression are also defined, hi the printer example, a search 
operation could be used to locate a LaserJet printer in the 
eng/os department that s u pp or ts the PostScript™ formal. 

The XFN API has been mapped to Internet DNS, CCITT 
X.500, DCE CDS, and ONC NIS+. Since X.500 provides the 
most functionality of these naming systems through its XDS/ 
XO.M API. this naming system presented the most challenges 
for XFN. XFN captures the functionality of XDS/XOM but is 
a simpler, more intuitive API. 

Support for Composite Names 

XFN specifies a syntax and parsing rules for composite 
names. Operations to manipulate these names are also 
provided. 

"A composite name consists of an ordered list of zero or 
more components. Each component is a string name from 
the namespace of a single naming system and uses the nam- 
ing syntax of that naming system. A component may be an 
atomic name or a compound name from that namespace." 
The string fonn of a composite name is "the concatenation 
of the components from left-to-righl with the XFN compo- 
nent separator (/) between each component." 

hi the DCE composite name /.../ch.hp.com/sec/principal/|smith 
mentioned earlier, the ch.hp.com component is a compound 
name in the DNS naming system, whose syntax is riglu-lo- 
ieft '.' separated. The second component, sec, is in the DCE 
CDS naming system, whose syntax is left -to-right 7' sepa- 
rated, like XFN's syntax. The final two components, principal/ 
jsmith. are in the DCE security naming system. This naming 
system's syntax is also left-to-right 7' separated. Since a 
component is defined as the name between two XFN separa- 
tors, principal/jsmith is two components even though both are 
in the same naming system. 

Composite names are formed when naming systems are 
joined by binding location information about a context in 
one naming system into its parent context in another nam- 
ing system. This location informal ion about a context in 
another naming system is called a ne.ct->i<iiiii)i(j-si/sleiii 
pointer. For most naming systems a next-naming-system 
pointer is bound to a leaf name in its namespace and is 
treated like any other name in its namespace. The location 
information is represented in an XFN reference. The XFN 
bind operation can be used to create next-naming-system 
pointers. 

Fig. 2 shows how the name /.../Wiz.com/user/jsmith/fs/naming/ 
memo.txt is composed. /... is a reserved token that indicates 
the root of a global naming system. The Wiz.com component 
is a name in the DNS naming system, user/jsmith/fs is in the 
DCE CDS naming system, and naming/memo. txt names a DFS 
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file. Location information about the DCE CDS context in 
which user is bound is associated with the name Wiz in DNS. 
The atomic name fs is bound in the CDS context user/jsmith lo 
an object reference with location information of jsmith's 
home directory in DFS. Wiz and fs are next-naming-system 
pointers. 

The XFN framework controls path resolution of a composite 
name. To resolve /.../ Wiz.com/user/jsmith/fs/naming/rnemo.txt the 
XFN framework first invokes the DNS context implementa- 
tion to resolve Wiz.com. The DNS context implementation 
makes libresolve calls to gather the information it needs to 
form the XFN reference associated with Wiz.com, which it 
returns to the framework. The framework inspects the refer- 
ence and invokes the context implementation specified in 
the reference. The framework passes to the context imple- 
mentation the location of the starting context for resolution 
and the remaining components to be resolved, hi this exam- 
ple, the context implementation is for DCE CDS, the stalling 
context is the one named by Wiz.com. and the name to be 
resolved is user/jsmith/fs/naming/memo.txt. CDS can only resolve 
user/jsmith/fs. II returns the XFN reference bound to user/ 
jsmith/fs and the remaining components to lie resolved back 
to the framework. The framework then passes the remaining 
name, naming/memo.ttt, to the file system to complete the 
resolution. 

XFN Protocols and Configurations 

XFN specifies client-server RPC interfaces for use with two 
RPC protocols: DCE RPC and ONC RPC. The protocols sup- 
port the operations in the XFN API. New naming systems 
and some current ones are expected to use one of these 
protocols for their client/server communications. 
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"The advantage for naming systems that export an XFN pro- 
tocol is that any existing XFN client that imports the proto- 
col can be used to communicate with it. This is particularly 
useful for applications that need to export naming inter- 
faces. Application programmers do not have to duplicate the 
client-side implementation and they do not have to invent 
new naming interfaces. This provides additional benefits 
such as the ability to use caching and other mechanisms 
provided by the XFN" client implementations, and a direct 
i and possibly more efficient ) mapping of XFN operations to 
the naming operations." 

The XFN naming model presents a hierarchical namespace 
that incorporates different naming systems. The naming 
systems are connected together into three levels. The top 
level is a global namespace: X.500 and UN'S are expected to 
control this level. The next level is an enterprise namespace: 
DCE CDS. ONC MS*, Banyan Streettalk, and Novell NDS 7 
are considered enter]) rise naming systems. The third level is 
the application namespace. The DCE security service, a file 
system, and a desktop support application namespaces. 

The XFN model, API. and protocols provide a toolkit for 
configuring naming federations in various ways. Fig. 1 illus- 
trates a heavyweight XFN client system with context imple- 
mentations and client-side code for five naming systems and 
a module that imports an XFN protocol. Fig. 3 shows a light- 
weight XFN client system that only runs the naming module 
thai imports an XFN protocol. Multiple name servers export 
the XFN protocol. Two of the name servers use a variation 
of their context implementations to map arriving XFN calls 
to their naming systems' native operations. These servers 
also export their native protocols to support clients running 
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legacy software. The desktop application was originally 
written to export its namespace with the XFN protocol. 

The two systems shown in Fig. 4 are a lightweight XFN cli- 
ent and a server that acts as an intermediary. Like the client 
in Fig. 3, the XFN client in Fig. 4 only inns the naming mod- 
ule that imports an XFN protocol. None of the legacy sys- 
tems' client-side software needs to run on this system. De- 
pending on the client system's requirements, the XFN client 
can he implemented and configured to consume more or 
less resources. For example, the XFN client might defer to 
the caching mechanisms provided by the native naming 
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system clients. "The legacy naming system clients in Fig. -J 
reside on a remote system (similar to Fig. 1) that also ex- 
ports the DC'E XFN protocol. This remote client can be 
viewed as a surrogate or proxy client that acts on behalf of 
the initial requestor and performs the native naming system 

Functions." 

Another common XFN configuration combines Figs. :i and 4. 
Some name servers export the XFN protocol and can he 
accessed direcily from the lightweight XFN client. Other 
name systems are accessed via an XFN surrogate client 

XFN Enterprise Policies 

The three-level hierarchy of global, enterprise, and applica- 
tion namespaces is an XFN policy thai was mentioned in an 
earlier section. Major entities, such as countries and organi- 
zations, are named in the global namespace. Names in a 
global naming system change infrequently and require sanc- 
tion from a global authority to do so. The enterprise name- 
space is assumed to contain names that are local to an orga- 
nization. XFN policies provide some guidelines for 
structuring an enterprise namespace. These policies do not 
apply to the global or application namespaces. 

XFN policy recognizes that there are commonly named 
objects in an enterprise. These are organizational units, 
users, hosts, services, and files. XFN policy reserves tokens 
tc i identify namespaces for these objects and also applies a 
relationship between them. Table I summarizes XFN enter- 
prise policies. Some examples of names that use XFN poli- 
cies are: 

/.../Wiz.com/_orgunit/r-d/eng/os/_user/|smith/_fs/naming/memo.txt. 
Names jsmith's file naming/memo.txt. jsmith is a user in I he 
r-d/eng/os department of the Wiz.com company. 
A../Wiz.corn/_orgunit/sales/_user/m|ones/_service/calendar. Names 
the calendar service for miones who is a user in the sales 
department of the Wiz.com company. 

/.../Wiz.com/_orgunit/newton/bldg300/conf-rm/chaos/_service/calendar. 
Names the calendar service for the Chaos conference room 
in building 300 of the Newton site of the Wiz.com company. 

Programs that use XFN policies are more portable across 
computing environments and enterprises. A distributed ap- 
plication, such as a calendar service, has a standard place (a 
.service context ) to put its binding information. An adminis- 
trator can put information about each user and each host in 
a central, predictable place. An end user can more easily 
figure out how to name another users files, for example. 

Despite the fact that .XFN policies are minimal, they are 
controversial. Standard token names raise concerns of name 
collisions. XFN specifies these tokens on the premise that 
the benefits of a more structured namespace outweigh the 
risk that XFN tokens will collide with names that are al- 
ready in a namespace. An XFN implementation can sacrifice 
its portability and customize its own tokens to identify the 
namespaces for common objects. An XFN implementation 
can conform to the XFN API but to some or none of the XFN 
policies. An enterprise namespace will normally have many 
contexts that are outside of the XFN policy domain and may 
have additional policies of its own. 
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Context Type 


Context 
Type 
Token 


Parent 
Context 


Subordinate 
Context 


Organiza- 
tional 
1 "nil 


_orgunil 


enterprise root 


user. host, 
file system, 
service 


1 SCI 


_user 


enterprise root, 
nrganizatinn:i 1 
unit 


service, 
file system 


I lost 


JlOSl 


enterprise root, 

organizational 
unit 


service, 
file System 


Service 


_service 


enterprise root, 
organizational 
unit, user, host 


not 

specified 


File System 


_fs 


enterprise root, 
organizational 
unit, user, host 


nol 

specified 



Other Naming APIs 

Some naming APIs, such as the Dt'E RPC Name Service 
Independent (NSI) Interface 8 and the OMG Common Object 
Service's Naming Service Interface, 9 are customized inter- 
faces thai may be layered over an XFN API and its 
implementation, 

The RPC NSI provides a high level of abstraction for navi- 
gating a namespace and yielding DCE RPC location informa- 
tion in the form of RPC binding handles. The OMG naming 
interface is a subset of the XFN basic context interface. The 
OM(! interface maps names to CORBA object references. 
Unlike RPC NSI and the OMG naming interface. XFN ac- 
cepts many different types of object references and provides 
mechanisms to extend the set of object references. Also, 
neither the DCE RPC NSI nor the OMG naming interlace has 
support for attributes. 

When these customized interfaces are implemented over 
XFN. they take advantage of XFN benefits such as portabil- 
ity and federation and they leverage all the software that 
supports the XFN API. 

Conclusions 

Among the benefits that XFN provides are: 

A uniform naming interface for accessing different naming 

systems. 

Application programming interfaces as well as RPC inter- 
faces. 

A naming syntax for composite names. 

Operations to join different naming systems together into a 

naming federation. 

A framework that supports the addition of new naming sys- 
tems to an XFN federation with no changes to applications 
or to current member naming systems. A naming system 
that joins a federation must only supply a context imple- 
mentation that maps the XFN API or an XFN protocol to its 
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native operations. Otherwise, the naming system's software 

is nol changed. 

Support for small clients. 

Easier administration of the various naming systems in a 
distributed computing environment. Browsers and editors 
that are written to the XFN API can access an entire feder- 
ated namespace. 

Application power. XFN applications can access a wide va- 
riety of naming systems through the same simple, yet func- 
tional API. 

Future Directions 

Future work needs to he done on policy. Different vendors 
that offer similar applications need guidelines for sorting out 
t heir uses of the namespace. I'sers sometimes want to se- 
lect among similar or replicated services based on network 
topology or load balance. Administrators often have com- 
mon information about a group of users and customized 
per-user information. Namespace policies and software 
could support these requirements. 
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HP Integrated Login 



HP Integrated Login coordinates the use of security systems and improves 
the usability of computer systems running the HP-UX* operating system. 

by Jane B. Marcus, Navaneet Kumar, and Lawrence J. Rose 



The HP Integrated Login product provides major usability 
gains for customers deploying enhanced security technolo- 
gies on computer systems based on the HP-UX operating 
system. In this article, we describe the customer needs and 
the IIP Integrated Login solution. 

As computer networks expand, and as pirates more fre- 
quently travel the information superhighway, customers 
require more stringent methods for securing data and ac- 
counts. The base HP-UX operating system provides standard 
UNIX 11 security mechanisms, but these do not meet all the 
needs of security-minded customers. There are many secu- 
rity tecluiologies available commercially and in the public- 
domain. IIP customers sometimes wish to deploy one or 
more of these technologies on the HP-UX platform. 

Security technologies use passwords to verify the user's 
identity and determine access rights to data and services, A 
user must enter a password and the password must be veri- 
fied before access is granted. For example, basic HP-UX 
security requires that a password be entered for the user to 
gain access to the HP-UX machine. In addition to machine 
entitlement, passwords also may be used to verify the user's 
right to access protected services (e.g., mail systems ) in die 
user's environment. 

Security-minded customers see many benefits to deploy- 
ment of enhanced security technologies — for example, pro- 
tection against impostors and network eavesdroppers. I low- 
ever, placing additional security technologies on top of the 
HP-UX system can create a burden to the users of the sys- 
tem. When multiple security technologies are deployed (to 
monitor access to various protected services in the user 
environment), each technology requires password verifica- 
tion. Thus, a user may be forced to type in a password for 
the HP-UX system and then for each additional security 
technology. Furthermore, the use of multiple security tech- 
nologies creates a complex task for users when passwords 
need to be changed in multiple places. 

Customers need enhanced security, but they also want us- 
able systems. Customers want to operate in a familiar envi- 
ronment, and do not want to leant many new commands for 
accomplishing basic tasks. When faced with a lengthy or 
complicated process, typical users may ultimately compro- 
mise the security of their systems by writing down pass- 
words and procedures that might otherwise be forgotten. 
Customers will not accept a burdensome process for their 
users. 



IIP Integrated Login 

The HP Integrated Login product has evolved to meet the 
customer needs discussed above. The original product for 
the HP-UX 9.x operating system was developed in response 
to DCEt customer requirements and was delivered primarily 
for use by HP's DCS customers. However, with the HP-UX 
10.0 release, the HP Integrated I-ogin product has been made 
extensible, so dial il can serve the HP-UX community at 
large. The latest HP Integrated Login provides library inter- 
faces that allow a generic set of security technologies to be 
integrated with HP-UX. The customer has maximum flexibil- 
ity lo choose and deploy appropriate technologies. Since 
DCB has an outstanding security technology, we exited that 
HP Integrated Login users will most often choose IK K for 
their security needs, but the HP Integrated Login product 
can support other tecluiologies equally well. 

The primary purpose of the HP Integrated Login product is 
to allow HP-UX users a convenient method for incorporating 
other security technologies into the standard HP-UX envi- 
ronment. L'sers should be able to use familiar HP-UX tools 
to accomplish familiar tasks. Thus, HP Integrated Login ex- 
tensions have been added to sev eral standard HP-UX 10.0 
utilities. 

The most important functionality delivered by HP Integrated 
Login is a single-step login: the user enters a password once 
at login lime, and this password is used to grant access to 
the HP-UX machine as well as verify access among all the 
configured security technologies. The HP-UX 10.0 com- 
mands login and su have been enhanced to include single-step 
login capabilities. Also, the HP user desktop (HP VUE) has 
been integrated to support multiple security technologies. 
Login information is propagated throughout the entire VI IE 
session and logins need not be repeated when new VUE 
windows are opened. 

Password consistency is fundamental to most HP Integrated 
Login deployments. A user chooses one password, and this 
password is adopted across all security technologies. Thus, 
the user can supply the password once and the HP Inte- 
grated Login utilities transparently perform logins to each 
configured security technology on behalf of the user. The 
ffiMJX 10.0 passwd command has been integrated to syn- 
chronize passwords for the user, so that a requested pass- 
word change can be propagated to all configured security 
technologies. Likewise, user information commands chin and 

t DCE is the Distnbuiefl Computing Environment. See article page 6 
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chsh are provided to allow changes 10 finger and user shell 
information across security technologies. ( Finger informa- 
tion includes the user's real name, location, and telephone 
number.) 

It is typical of the UNIX operating system thai sev eral opera- 
lions are password-controlled — for example, file transfer to 
or from a remote machine and screen lock or unlock. Inte- 
grated file transfer protocol (ftp) and IIP VUE lock utilities 
have been provided. Consistent with other HP Integrated 
Login utilities, these operations verify user access for all 
configured security technologies based on one user-supplied 
password. 

The HP Integrated Login product provides extensions to 
HP-UX commands to support multiple security technologies 
on top of the HP-UX system. The extension method involves 
a new shared library provided with HP-UX 10.0. Integrated 
HP-L*X utilities make calls to this shared library (libauth. si ). 
The libauth library calls handle various security tasks such as 
password verification for login and password changes. Thus. 
HP-UX utilities relinquish to libauth the direct responsibility 
for supporting diverse security technologies. Furthermore, 
these HP-L T X utilities have no awareness of multiple security 
technology configurations, and have no knowledge of t he 
details of how these security technologies function. 

HP Internal Customer Needs 

Enhanced security technologies on top of HP-UX have ex- 
isted for some time. Before (he creation of HP Integrated 
Login, several security technologies had independently been 
integrated into the HP-UX system. Each security technology 
had its own login method, and each security product would 
spin off new versions of HP-UX login commands and HP 
VUE to incorporate the technology's login implementation. 
These efforts were difficult lo coordinate, and there grew to 
be many different versions of HP-UX login commands to 
accommodate all of these security technologies. One HP 
Integrated Login goal was (o replace the myriad of login 
implementations with one generic login methodology. This 
was expecteil lo solve a number of different problems, in- 
cluding the IIP support cost lo maintain mulliple code- 
bases. The solution required the definition of a generic login 
procedure, flexible enough to accommodate all the existing 
login methods. 

Extensibility 

HP Integrated Login supports mulliple security technolo- 
gies. The HP Integrated Login configuration file declares 
which technologies are being integrated. Typically, the 
HP-UX machine administrator uses IIP Integrated Login 
administrative tools to create and maintain this configura- 
tion file. Each technology declared in HP Integrated Login's 
configuration file must provide a technology shared library. 
This shared library will be dynamically loaded by the IIP 
Integrated Login library (libauth), which coordinates all un- 
derlying security technologies. The libauth library determines 
the names of the technology shared libraries and the order 
in which lo load them based on the contents of the HP Inte- 
grated Login configuration file. Fig. 1 shows the resulting 



109m 




Program 




Shared 
libra ry 




load 


Password 


Progfimi 





Interface 



Interlace 




Ott Security 
Tethnologi 
Shared library 



UrJief Stcurrty 

technology 
Sharer) Library 



Other Security 

technology 
Shared library 



Fig. I, Tin- extensible architecture of HP Integrated Login. 

architecture. The libauth library needs no special knowledge 
of any security teclmology library that it loads. Well-defined 
interfaces exist between the libauth coordination library and 
the security technology shared libraiy. 

From HP-UX commands, the following can occur. 

» The HP-UX command dynamically loads the HP Integrated 
Login shared library ( libauth). 

» The libauth library reads the HP Integrated Login configura- 
tion file and dynamically loads the configured security tech- 
nology libraries. 

• The HP-L'X command makes library calls to libauth 10 handle 
login and password functions. 

» The libauth library makes library calls to security technology 
libraries. 

An exception in the IIP Integrated Login library strategy is 
the method by which basic HP-UX security is provided. 
While the HP Integrated Login configuration may specify the 
use of basic HP-UX security, there is no HP-I X technology 
libraiy to be dynamically loaded. Rather, the HP-UX com- 
mands handle basic HP-UX functions from within the com- 
mand code. 

The libauth library is shipped with the IIP Integrated Login 
product, and is dynamically loaded by the integrated HP-UX 
commands and HP VUE. HP-UX utilities use libauth to inte- 
grate security technologies, but the basic HP-l'X security 
code is always accessible since it is contained within the 
HP-UX utilities. Thus the HP-UX 10.0 ulililies can still pro- 
vide standard HP-UX functionality on systems that do not 
have libauth installed. While the integrated commands must 
be aware of their use of libauth. the commands are com- 
pletely unaware of libauth's use of underlying security tech- 
nology libraries. 

Configuration of Multiple Technologies 

The HP Integrated Login configuration file is used 10 define 
a login policy to be used on a particular machine. The policy 
specifies which technologies are in use. When multiple secu- 
rity technologies are in use. the relative priority of these 
technologies must be configured for HP Integrated Login 
operation. One technology is configured as the primary login 
technology. This primary login leclmology will be the inilial 
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technology to be consulted for user password verification. If 
the primary login succeeds, the user will be grained access 
to the HP-l.'X machine, and additional logins can then pro- 
ceed (transparently) to verify the user with oilier security 
technologies. 

In case the primary login does not succeed, a fallback tech- 
nology can be configured. If tl ser can be verified with 

the fallback security technology, the user is granted access 
to the HP-l.'X machine, and again, other configured logins 
can then proceed. 

The importance of the fallback strategy cannot be under- 
stated. Security technologies often have dependencies on 
network communications and cannot function if the net- 
work is not intact. For some customers, it is unacceptable 
for users to be denied access to their local machines be- 
cause of network problems. The HP Integrated Login fall- 
back strategy allows customers who require a high level of 
robustness to use HP products with confidence. 

The relationship between the primary login technology and 
the fallback login technology must be well-understood. In 
some cases, the primary login technology may attempt to 
synchronize the fallback technology with current user infor- 
mation. For example, when DCE serves as the primary login 
technology, it is an IIP Integrated Login option to automati- 
cally populate the HP-UX user information database (i.e., 
the /etc/passwd file) with information from the DCE security 
database. In most cases, the /etc/passwd file will never be 
accessed at login time, because DCE. as the primary login 
technology, will verify the user. However, when DCE is un- 
available, HP-UX login security can be used as a fallback to 
log in all users known to DCE. Such an arrangement is ad- 
vantageous for administrators who want to maintain user 
accounts in one primary location, but also want to facilitate 
fallback logins where necessary. 

In other cases, administrators may purposely wish to main- 
tain some users in one security technology database and 
other users in a different security technology database. Tin- 
HP Integrated Login configuration of primary and fallback 
login technologies can facilitate this process. The HP Inte- 
grated Login libauth library will consult the primary login 
technology first to verify the user, but if this user is not 
known to the technology. HP Integrated Login can be config- 
ured to consult the fallback login technology. 

In addition to configured primary' and fallback login technol- 
ogies, other login technologies can be configured. These 
logins will be done transparently for the user, in the order in 
which they have been configured with HP Integrated Login. 
The purpose of these additional logins may be to enable user 
access to some protected service in the user's environment. 
These additional logins will only be attempted if the primary 
or fallback login has succeeded, that is, if this user has been 
granted access to the HP-UX machine. Errors occurring with 
these additional logins are nonfatal, meaning that the user 
session can proceed .-ven if one or more of these additional 
logins fails. 

The organization of technologies in the configuration file is 
used by libauth to determine the order in which technologies 
should be loaded and accessed. We call libauth's ordering of 



technologies the policy chain, and it reflects the configura- 
tion of primary login, fallback, and additional login technol- 
ogies. The policy chain is used by libauth to make decisions 
on how to sequence through the configured technologies. 

The configuration file may also contain directives to libauth 
regarding handling of login errors. These directives logically 
become pan of libauth's policy chain and determine Mwuftfa 
actions in the event of login failures. For instance, the con- 
figuration file may specify that a login failure because of an 
incorrect password entry should result in a denial of nta- 
< him- access, regardless ot whether this password may be 
verifiable by other configured technologies in the policy 
chain. The libauth library's actions in this case would be to 
stop the login sequence after the initial failure and rHrain 
from cycling through the security technologies. The behav- 
ior of libauth is configurable, so it is also possible to specify a 
configuration that authorizes libauth to pass the login request 
to the next technology in the policy chain. 

The configuration file also includes a mechanism to pass 
configuration information to the security technology li- 
braries that will be loaded by libauth. Configurable parame- 
ters can be specified for each specific security technology. 
These parameters are meaningful only to the security tech- 
nology - library and are determined by the security technol- 
ogy library provider. For instance, a specific security tech- 
nology may support the notion of a session lifetime. A 
configurable parameter called LIFETIME may exist in the IIP 
Integrated Login configuration file to be passed to the secu- 
rity technology when being loaded by libauth. The libauth li- 
brary will pass the configuration information to the security 
technology library, but will not use or process this informa- 
tion in any way (thus preserving the extensibility model i. 

libauth Login Processing 

To accomplish a login that results in a user session, several 
behind-the-scenes events must occur. The procedure con- 
sists of three phases: the initialization phase, the login 
phase, and the session-setup phase. 

During the initialization phase, the HP Integrated Login 
policy is read from the configuration file. The libauth library 
proceeds to load the security technology libraries and 
charges them to run through their respective initializations. 
Initialization failures from any of the security technology 
libraries cause libauth to mark the technology as inaccessible. 
When security technologies are inaccessible, libauth must 
adjust its understanding of the policy chain to reflect the 
effective policy. Upon successful initialization, libauth and the 
security technology libraries exchange entry point informa- 
tion. This makes it possible for two-way communication to 
occur between the security technology library and libauth. 
The libauth library can now call the security technology li- 
brary interfaces to handle security tasks, and the security 
technology libraries can communicate messages and error 
status. 

The login phase is a two-step process. Step one determines 
whether the user should be granted access to the local sys- 
tem. Prompts are issued for the user name and password, 
and subsequently the primary login technology library is 
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called to verify access. Logically, this step may lie consid- 
ered a Boolean operation which simply returns a yes or no 
answer regarding the user's entitlement to access the local 
system. Depending upon the configured policy' chain, libauth 
may continue on failure to the configured fallback technol- 
ogy, or may deny access. 

The second step in tliis login phase (after having granted 
machine access) is to complete any additional logins that 
should be done. These additional logins may be needed to 
enable operations with some protectee! services once the 
user session logins. In current implementations, additional 
logins can only succeed if the password entered is valid for 
this user across all security technologies. However, libauth 
code js in place to support different passwords for addi- 
tional security technologies, although this code is not yet in 
practical use. The method for supporting multiple pass- 
words depends on the primary login technology's ability to 
securely store passwords to be used with other security 
technologies. A successful login with the primary login tech- 
nology would result in the stored passwords being passed to 
libauth for use with the other technologies in the policy chain. 

The session-setup phase is for establishing the user session. 
The information about how to set up the session is retrieved 
from the underlying primary login technology database, hi 
particular, the user and group IDs must be set. for the new 
session, and the user shell must be started. In addition, the 
exportation of environment variables occurs. If any config- 
ured technologies require special environment variables to 
be set, these environment strings are passed back to the 
HP-I "X command so that they are exported at session-setup 
lime. 

Password and Information Processing 

The libauth library interfaces oversee changes to user infor- 
mation, such as password, user shell, and linger informa- 
tion. The HP-UX passwd command, for example, loads libauth 
to coordinate password changes. The libauth (and technology 
library] initialization phase described for login processing is 
the first step here as well. 

Before calling libauth to make ;t password change, the passwd 
command calls libauth to Check the new password that has 
been proposed. Most security technologies apply password 
strength checking algorithms to newly created user pass- 
words. These algorithms test whether the new password 
meets certain criteria. For example, one HIM X rei|iiiremenl 
is that the new password must have at least I wo alphabetic 
characters and at least one numeric or special character. 
For password Strength checking, a libauth interface deter- 
mines if the selected password is acceptable to all config- 
ured security technologies. The password is rejected if any 
of the security technology libraries rejects it. and the opera- 
lion fails. 

If the proposeil password is acceptable, the command calls 
libauth to contact the primary login technology. The primary 
login technology will then change the password in the pri- 
mary login technology's user database. Failure to change 
information correctly with the primary login technology 
causes the entire operation to fail. If the change succeeds, 
libauth follows the policy chain lo request password changes 
in all other security technology databases. If a failure occurs 



for this user with any of the additional ( i.e.. optional ) tech- 
nologies, an error indication is recorded and the next tech- 
nology in the chain is tried. If a failure occurs during a pass- 
word change operation, the password may no longer be 
consistent across all technologies. An error indication 
clearly states this and gives advice on how to remedy the 
situation manually. 

Some details of the policy chain configured in the HP Inte- 
grated Login configuration file do not apply to password 
processing The configuration file is used to determine the 
primary login technology. However, libauth passwonl inter- 
faces make no attempt to deal with a configured fallback 
technology in case of error. 

The libauth library interfaces allow other user information to 
be changed. The user's shell c an be also changed. In all 
cases, changes to user information start by attempting to 
make the change in the database of the primary login tech- 
nology. Successful changes cause the operation to continue 
down I he policy chain to completion. 

Oilier libauth Interfaces 

Aside from password and login functionality, other libauth 
interfaces are available lo HP-UX commands. 

For security technologies that include the concept of login 
expirations, libauth supports a refresh operation. For exam- 
ple, suppose that the user's machine has been left locked by 
the VUE screen lock pr og ram, and the user's login expires 
before the user returns to unlock the machine. The libauth 
refresh interface allows bypassing some of the details of the 
full login process, although reprompting of the password is 
required for ibis step to maintain security. 

Another libauth interface resets the current login information. 
This interface is used by commands that can switch be- 
tween users, suc h as ftp and su. The reset action cleans up 
any residual login informal ion. effectively terminat ing a pre- 
vious login across all security technologies. 

('housing a Primary Security Technology 

An IIP Integrated Login goal is to simplify user administra- 
tion among multiple security technologies. When multiple 
security technologies are deployed, multiple user informa- 
tion databases may coexist. These registries are reposito- 
ries of user-related information, and different technologies 
require the storage of different types of informal ion aboul a 
user. HP Iniegraied Login configuration of a primary login 
technology determines which registry is most important for 
maintaining user information. The primary login technolo- 
gy's registry assumes the role of the main location for user 
information, and registries from other technologies are log- 
ically subservient, For example, if the passwonl I hat the 
user has provided is determined lo be incorrect when 
checked against the main registry. IIP Integrated Login may 
he configured to deny access Without further checking of 
the password against other technology registries. If the user 
requests a c hange of password and for some reason the 
main registry cannot entertain the change, no attempt is 
made lo request the change in other registries. 
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When deploying multiple security technologies, the choice 
of the main registry is very significant. System administra- 
tors might ask what features such a registry should have. 
Especially in a networked environment, this registry must 
he highly available and reliable, since users may he denied 
access if it is not in operation. The main registry must be 
capable of storing critical user information, including but 
not limited to user name, user identifier, password, group 
identifier, home directory, and login shell. Since user infor- 
mation is likely to change as we move towards more complex 
systems, built-in extensibility of the registry is highly 
desirable. 

We find DCE to be an excellent choice for the main security 
technology. The IK E security service registry Satisfies all 
basic requirements for a main registry. 

The I K E registry is highly available. The implementation 
allows for a collection of one master and several replicas, so 
user information can be obtained from multiple (but consis- 
tent) sources. Replicas are copies of the master information 
and are read-only sources of information. If a replica goes 
out of service, others are available to provide user informa- 
tion. If the master goes down, a suitable replica can be 
transformed into a master. If service degrades because of 
heaVy demand, additional replicas can be added to expedite 
requests ( 'onscquently, the service is si alable and reliable, 

DCE uses Kerberos™ authentication protocols and is highly 
secure in a distributed environment. For example. DCE does 
not transmit passwords in the clear across the network. This 
feature is not particularly useful if other technologies do 
otherwise, but the main registry should not he the weak link. 

The OSF DCE 1.1 registry is extensible. System administra- 
tors can extend the registry to hold arbitrary user informa- 
tion. For example. DCE 1.1 uses this extensibility feature to 
support password aging (mandating that passwords be 
changed regularly) and password strength checking. 

DCE is serviceable. Logging and audit trails can be used to 
diagnose error conditions. 

In summary, we find DCE to be the logical choice for the 
primary login technology and to serve as the main registry 
of user informal ion. (See the article on page -11 for more 
information about DCE security services.) 

Login Access Using HP Integrated Login and DCE 

Although the HP Integrated Login design does not require it. 
our implementation works very well with DCE providing the 
main registry of user information. This solution is robust 
and allows administrators to focus their efforts on maintain- 
ing user information in one location: the DCE registry. Fig. 2 
illustrates how HP Integrated Login uses tbe DCE registry. 

Customers with robustness requirements often choose to 
configure HP-UX security' as a fallback technology. As de- 
scribed earlier, the fallback technology is used when the 
primary login technology is unavailable. With DCE as the 
primary login technology, DCE is unavailable when the net- 
work is not operational. Since HP-UX security is local to the 
machine and is unaffected by network errors, an HP-UX 



Tailback may be a good choice. However, if the fallback reg- 
istry is to provide access that is consistent with the main 
registry, it must be kept consistent with the main registry. 
Support for keeping the registries synchronized is obviously 
needed 

For this purpose, DCE provides a tool, passwd export, that 
exports the information in the DCE registry to the native 
HP-UX registries, /etc/passwd and /etc/groups. When IIP Inte- 
grated Login is installed, a system administrator can config- 
ure the HP-l'X command cron to run passwd export periodi- 
cally to keep the registries consistent. 

D( E user accounts are valid across the DCE network envi- 
ronment. Once established in tbe DCE registry, a DCE user 
can log in from any machine in the user's DCE environment, 
with no other special administration required. The DCE reg- 
istry is implemented as a centralized network service, with 
requests travelling back and forth over the network from the 
registry to the c lient machines. However, DCE allows regis- 
try user information to be overridden at the local machine 
level. In this case, information is taken from the local ma- 
chine rather than from the DCE network registry. An over- 
ride mechanism is important to machine administrators 
wishing to customize their individual machines. For exam- 
ple, in a traditional ("NIX system, each machine has a super- 
user account root. Machine administrators do not want the 
root account to share a password with all root accounts on 
machines in the DCE networked environment. Rather, ma- 
chine administrators want to maintain the password for the 
root account locally. In this case, administrators must over- 
ride the information in the main registry in favor of informa- 
tion stored on the local machine. 

To handle such cases. DCE provides support for an override 
file. This file has a format similar to the traditional UNIX 
/etc/passwd file. If a user is maintained in the override file, the 
user's access to the machine is verified based on the over- 
ride file entry and is not verified by the DCE registry. By 
common use. root is maintained in the override file to ensure 
that for superuser privileges a local password is required. 
The DCE override file is only readable by the superuser ac- 
count and as such is more secure than tbe 1IP-1 "X /etc/passwd 
file. 

Since DCE is a scalable, reliable, and secure service, some 
installations with especially stringent security requirements 
may wish to disable fallback login verification. In general, 
customers can rely on DCE to provide consistent service as 
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long as the network is operational Some customers disable 
fallback to basic HP-UX security because the HP-UX /etc/ 
passwd file is inherently less secure than many customers 
require. For HP Integrated Login DCE configurations with 
BO fallback technology, most logins will be disabled if there 
are network problems. However, users being administered 
in the DCE override file will still have login access in case of 
network failure, since the override file is stored on the local 
machine and is unaffected by network errors. 

Login Information Maintenance: DCE and HP-UX 

Suppose HP Integrated Login has been configured with DCE 
as the primary login technology and HP-UX security pro- 
vides the fallback technology. 

Example 1. A user wishes to change a password We have 
two registries to consider: DCE and HP-UX. The following 
sequence of evenls occurs: 

Since DCE is the main registry, the old and the desired new 
passwords are obtained and passed to the DCE security 
technology library'. 

The DCE registry verifies that the old password was correct 
and further determines if the new password is strong 
enough. If these checks pass, the user's password is 
changed in the DCE registry. 

No attempt is made to contact the fallback registry (/etc/ 
passwd) at this time. However, iibauth could propagate the 
password change to other configured technologies. 
After a certain interval configured by the system administra- 
tor, passwd_export rims and exports the changed password 
information to t he HP-UX /etc/ passwd file. Thus, the fallback 
plan to lll'-l "X remains intact with this synchronization. 

Example 2. A user whose account information is stored in the 
DCE override file requests a password change: 
The Iibauth library passes the request to the DCE security 
technology library. When user account information is kept 
in the DCE override file, passwords are changed in the over- 
ride file only. The DCE registry is not changed at all. 
When passwd_export runs, it exports the changed password 
from the override file to /etc/passwd. This is how the local root 
user can change its password. 

Example 3. A user requests a shell change: 
The chsh command calls Iibauth to pass the new shell infor- 
mation to the primary login technology library ( DCE). 
II configured, passwd_export runs and exports the changed 
shell information to the HP-UX /etc/passwd file Thus, HP-UX 
and DCE registries remain synchronized. 

If passwd_export is not run periodically, some traditional UNIX 
commands and library calls with dependencies on the /etc/ 
passwd file might use stale data. For example, the Is com- 
mand gets user Information from the /etc/passwd file. If the 
/etc/passwd entry for this user is not kept consistent with the 
information in the DCE registry, (he Is command may be 
relying on old data for this user. 

Login Information Maintenance: NIS and DCE 

Siijipi.se HP Integrated Login has been configured w ith 
HP -I X as the primary' login technology. By way of clarifica- 
tion, it should be noted that MS support falls under the 



generic HP-l"X umbrella because HP-UX c ommands have 
been integrated with NIS for several years. At present, the 
code to support NIS is retained in the HP-UX commands. 
Thus, when HP-UX security has been configured, this effec- 
tively can include NIS if it has been deployed in the HP-I "X 
environment. Currently there is no way to ensure full ac- 
count consistency between NIS and DCE because there is 
no NIS utility comparable to DCE's passwd_expon. Thus, users 
added to the NIS registry must also be added to the DCE 
registry by the system administrator 

Example 4. A user password change is requested and the 
HP-UX system (NIS) is the main registry, that is, password 
verification by NIS determines the users right to machine 
access. Suppose also that DCE has been configured for addi- 
tional login because users need access to some DCE 
services. 

• The user wishing the password change must present the old 
password and the desired new password. The passwd com- 
mand calls Iibauth. 

• The Iibauth library tells the passwd command that the HP-UX 
system has been configured, so the passwd command inline 
code handles this password change operation. 

• If the user's account is in the local /etc/passwd file, the pass- 
word is changed there. If the user's account is maintained in 
the central NIS registry, the password is modified there. 

• The passwd command calls Iibauth to propagate the password 
change to other configured registries. This request is passed 
to the DCE technology library and, if successful, results in a 
password change in the DCE registry. If for some reason the 
password cannot be changed in the DCE registry, the user is 
advised to try changing the DCE password again later. The 
passwd command now provides a command line option to 
change a password in a specified registry. 

The Single Sign-on Problem 

HP Integrated Login operates on HP-UX machines only. 
Much work remains to be done for customers who need a 
higher level of flexibility and integration. For example, a PC 
user on a Novell network would like to enter a password at 
network login lime and have this password also validate 
access for other integrated systems. Unfortunately, there are 
extremely complex problems associated with login and 
passw ord synchronization across operating systems and 
across hardware platforms. This larger problem is often 
called the single sign-on problem, and is being addressed by 
an industry working group of which I IP is a coleader. 1 

Summary 

The IIP Integrated Login product addresses the needs of 
customers wishing to deploy multiple security technologies. 
HP Integrated Login improves usability by providing single- 
step login. Options to configure fallback login technologies 
ensure robustness in the event of network failure. HP Inte- 
grated Login is especially convenient for customers deploy- 
ing DCE. because DCE and HP Integrated Login together 
provide the tools required for maintaining a high level of 
consistency between DCE and the HP-UX system for user 
account information. 
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The DCE Security Service 



A security protocol consisting of encryption keys, authentication 
credentials, tickets, and user passwords is used to provide secure 
transmission of information between two transacting parties in a DCE 
client/server enterprise. 

by Frederic- Gittler and Anne C. Hopkins 



The < >pen Software Foundation's I >islribtited < (imputing 
Environment ( DCE) is a collection of integral eil services 
that sappM the distribution of applications on multiple ma- 
chines ac ross a network. In most cases, networks are inher- 
ently insecure because ii is possible for someone to listen lo 
traffic or behave as an impostor. Without countermeasures 
this threat could prohibit the distiibulion of business appli- 
cations. 

The DCE security service described in this article provides a 
set of security mechanisms that can be easily used by a dis- 
Iribuied application lo remove Hie security vulnerabilities 

mentioned above. 

The security functionality provided by the DCE security 
service includes: 

• Identification and authentication of users to verify that Ihey 
are who they claim to be 

• Authorization for applications to decide if a user can access 
an operation or object 

• Secure dala conununications lo protect the data communi- 
cation of ;ui application against tampering or eavesdropping. 

Securitj Services 

The I ICE security sen ice. with additional new services and 
facilities, is based on the Kerhcros system.' The Kerberos 
system performs authentication of users and servers based 
mi cryptographic keys so that communicating parlies can 
(XUSl the identity of I he other. DCE augments Kerberos with 
a way lo transfer additional security attributes (beyond .just 
identity) to a server which may choose lo perform access 
control on those attributes. The DCE communication proto- 
col contains support for protected communications thai 
relies on crytographic session keys provided by Kerberos. 

Fig. 1 shows the environment in which the DCE security 
service operates, and the serv ices provided on the DCE 

security server, 

Registry. Every DCE security service user is known as a prin- 
cipal. Interactive (human ) users, systems (computers), and 
application servers (processes) are all principals. Each prin- 
cipal shares a secret key! with the DCE security server. The 
secret key for interactive users is derived from the user pass- 
word. This security model relies on the fact that a particular 
key is known only lo the principal and Ihe DCE security 
service. 

t As in the KeiUeros system, keys ate used tor encrypting and decrypting data translated in a 
network WnsacttOO, and am kriuwti only lo Hie DCf security setvet and lite parlies involved m 
Ilia liansactinn 



The registry service is the manager of the central registry 
database which contains the principal's name, universal 
unique identifier (IUID). secret key, I'NLX account attri- 
butes, and other attributes of the principals. These attri- 
butes include the extended registry attributes (ERA), which 
may be defined and instant iatetl by an administrator. 

Like other DCE services, access lo the ivgisi r\ serv ice is 
based on the use of remote procedure calls (RPCsj. The 
registry's operation is secure because it uses a protected 
RPC for all of its transactions. Extended registry attributes 
are covered in more detail later in this article. 



Administrator Security Server 




EPAC ■ Extended Privilege Attribute Certificate 

TGT = Ticket-Granting Ticket 

PTGT = Privileged Ticket-Granting Ticket 

Fig. l. The components of the DCS securitj/ server in relation in 

the nl her eiiiii|iiiiienls typically found in f distributed ••nvirounti-ii!. 
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Glossary 

The tallowing are same af the terminology and associated acronyms frequently 
used in this article. 

Extended Privilege Attribute Certificate (EPAC). A credential provided by the 
DCE privilege service containing user and group identities and attribute-value 
pans This information is used by an application server to make authorization 
decisions 

Extended Registry Attribute (ERA). A mechanism in which attribute-value pairs 
are associated with principals The information In these attribute-value pairs mav 
be used to deny or gram an authorization request. 

Principal. An entity such as a user, an application, or a system whose identity 
can be authenticated 

Service Ticket A credential used by an application client to authenticate itself 
to an application server. 

Ticket-Granting Ticket (TGT|. A credential that indicates that a user has been 
authenticated and is therefore eligible to get tickets to other services. 



Identification and Authentication. Tltc first interact inn between 
a user and the DCE security service is the login sequence 
when the identity or a user is authenticated hy a secret key. 
The result of this authentication is a ticket-granting ticket 
(TGT) containing the user principal's credentials. The TGT 
indicates that the user has been authenticated. It is used, as 
its name implies, to obtain tickets to other services, The life 
span of a TGT is limited to ensure thai the user represented 
by the credentials is the user currently using the system and 
that the user's credentials are up-to-date. 

The user and group identity and the extended registry attri- 
butes are not part of the TGT issued by the authentication 
service. The privilege service supports an additional autho- 
rization by providing user and group identities and attributes 
in the form of an extended privilege attribute certificate 
(EPAC). During a login sequence, after the TGT is obtained, 
the run-time DCE security service makes a request to the 
privilege serv er to issue a privilege TGT. This ticket is a 
combination of the TGT and a seal of the EPAC. 

The privilege TGT is stored in the user's environment and is 
used by the secure communication mechanisms to obtain a 
service ticket from the authentication service. The service 
ticket is used by the communication mechanisms to per- 
form mutual authentication between the application client 
and the application server, 

In each of these exchanges, secret session keys. Which are 
known only to the D( !E security service serv er, are generated 
for a particular session between the client and server. The 
DCE security run-time environment. KPC. and GSS (Generic 
Security Service)- API use these keys for data encryption or 
integrity protection generation in any network communica- 
tion during a particular session. A brief description of the 
GSS API is given later in this article. 

Authorization. DCE security provides application servers 
with multiple options for authorization. A server can choose 
to grant access lo a user based on one of the following three 
models. 

• Name-based authorization. The simplest but least scalable 
way of doing authorization is to compare the name of the 



remote principal with the names stored in an application- 
specific database. This method is called name-based autho- 
rization and is available when using the DCE secure com- 
munical ion meii uu i isms. 

• Privilege-based authorization with access control lists. DCE 
servers can choose to protect their resources with access 
control lists (ACLs). An ACL contains entries that describe 
the particular permissions granted to various principals. An 
ACL entry may specify an individual user (principal) name, 
a group name thai implies several principals, or "other" to 
indicate any principal not already matching a user or group 
entry. Users, groups, and others from a fore ig n cell may also 
be specified in an ACL entry, 

When a server receives a remote request, it asks the authen- 
ticated UPC run time environment for the caller's EPAC. The 
EPAC contains the caller's principal and group identities, 
wliich are compared against the ACL to determine if access 
is granted. If the caller's principal identity matches the prin- 
cipal in an ACL entry, and if I hat ACL entry contains the re- 
quired permissions, then access is granted. If there is no 
match on the principal, but one of the caller's groups matches 
a group ACL entry, then the permissions in the group entry 
apply. 

The DCE library includes facilities to manage ACLs and per- 
form authorization checks based on ACLs. ACLS are de- 
scribed in the article on page 49. 

• Other authorization. Other authorization mechanisms are 
made possible by the ERA facility. A server can use the 
value of any given attribute in a user's EPAC to decide 
whether it should service or deny any given request. 

Secure Data Communication 

DCE provides the remote procedure call (RPC) communica- 
tion mechanism as one of its core services. The DCE security 
service is designed to support protected KPC communication. 

Not all distributed applications in a DCE environment will 
use RPC. Most client/server applications in existence today 
are message-based, and changing them to use the RPC para- 
digm is expensive and time-consuming. It is also not practi- 
cal for certain applications to use RPC. These applications 
nonetheless require security. For this reason the DCE secu- 
rity service now supports the Generic Security Service API 
(GSS APT), which allows an application to authenticate itself 
to a remote party and secure data for transmission over an 
arbitraiy communication mechanism. 

Four basic levels of protection are available with either RPC 
or GSS API: 

• No protection. The DCE security service does not mediate 
or participate in the connection. 

• Authentication. The user of the client application is authen- 
ticated to the server. 

• Data integrity. A cryptographic checksum is included with 
the data transmitted. The DCE security service guarantees 
the data received is identical to the data transmitted. 

• Data privacy. The data is transmitted in an encrypted form 
and is therefore private to the sender and the receiver. 
L'nited States export regulations limit the availability of this 
level of protection outside of the l'nited States and Canada. 

The higher protection levels include the protections offered 
by the lower levels. 
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Security beyond DCE 

Logically, two login sequences are required: the login to the 
system and the login to DCE. Entries in the DCE security 
service registry contain all the attributes associated with a 
I WLX account. These entries can be used instead of the 
traditional /etc/passwd file or NIST database as the source of 
information for the UNIX system login. The HP-l'X* operating 
system integrates the system and DCE login sequences into 
an integrated login facility, which is described in the article 
on page 34. 

The DCE security service can be used as the core security 
service for the enterprise because it features an extensible 
registry through the ERA facility. Products from HP and 
other manufacturers licensing DCE from the Open Software 
Foundation (OSF) will undoubtedly use the extended regis- 
try attribute facility either to provide other integrated login 
facilities or to synchronize the DCE security service registry 
with other user databases. 

The sec ure data communication mechanisms described 
above can be used by system vendors to secure the standard 
network communication protocols, such as the file transfer 
protocol (ftp). 

Security Mechanisms 

The mechanisms used by the DCE security service to pro- 
vide secure data communication are a combination of key 
distribution, data encryption, and data hash tables. The pur- 
pose of this section is to give more details about these 
mechanisms. Some details have been omitted for brevity 
and readability. More formal and complete descrii.it ions of 
the algorithms can be found in the references indicated 
below. 

Data Encryption. The I >( K security service uses the Data 
Encryption Standard (DES) 3 algorithm to protect the dala it 
transmits. This algorithm is used by both UPC and the GSS 
API to protect user data and guarantee its integrity. DES 
requires that the two parties exchanging information share a 
secret key. which is only known to the I wo parties. This key 
is 04 bits long and has 50 bits of data and S hits of parity. 

DES encrypts plain text in blocks of (>4 bits. The encryption 
is obtained by the iteration of a basic operation which com- 
bines permutation of bits for both key and data with exciu- 
sive-OR operations. The result of the encryption is a block of 
cipher text in which each bit depends on all the bits of the 
key and the plain text. Decryption of the cipher text involves 
the inverse of the same basic operation. The party receiving 
the cipher text and performing the decryption has a copy of 
the key used for encryption. 

The DCE security service uses DES in cipher-bloek-chaining 
mode in which plain text blocks are exciusive-ORed with the 
pivv ions cipher text block before being encrypted. The DCE 
security service also uses confounder data, which is a 
dummy block of random data placed before the application 
data. Confounder data is used to prevent guessing by cor- 
relation bei ween blocks of encrypted data. The same block 
of plain text can result in two completely different blocks of 
data once encrypted with the same key because of the fact 

tNIS. or Network Informariori Services, is a product Irom Sun Miciosvstoms 



that the confounder data will be different. These two tech- 
niques render security attacks particularly difficult because 
each block of cipher text depends on lite previous c ipher 
block and some random data 

One-Way Hash. The DCE security service uses the message 
digest 5 (MD5) algorithm 4 coupled with the DES encryption 
algorithm to guarantee the integrity of the data being trans- 
mitted and verify the success of the decryption operations. 
MD5 produces a 128-bit signature (also called a message 
digest) that represents the data being transmitted This mes- 
sage digest is obtained by processing the data in bloc ks of 
512 bits. The algorithm is driven by a fixed table containing 
64 operations. It uses four 32-bit variables and involves rota- 
tion. exciusive-OR, OR. negation. AND. and addition operations 
on these variables and the 16 32-bit segments contained in 
eac h block. Like all one-way hash functions, MD5 is designed 
to be easy to c ompute and difficult to break (i.e.. derive 
plain text from a given hash ). DCE uses CCITT-32 CRC, 5 a 
checksum algorithm, to verify data integrity in certain cases. 

Keys. The DCE security service uses two types of keys: long- 
term principal secret keys and conversation or session keys. 

• Principal keys. The DCE authentication protocol ( described 
below) requires that the DCE security server and the princi- 
pal requesting authentication share a secret key. For a ma- 
chine or process principal, this key is stored in a file and is 
protected by the local operating system protection mecha- 
nisms. In the case of a human principal, the secret key is 
derived from the user's password by a one-way hash func- 
tion.' All the principal keys are stored in the DCE registry. 

• Conversation or session keys. Conversation and session 
keys are used to encrypt the data anil checksums exchanged 
between the application client . the application server, and 

I he DCE security server. The designs of the DCE and Ker- 
beros security mechanisms avoid the need to establish a 
long-term secret key for each pair of communicating princi- 
pals by creating short-lived session keys and commtinicat- 
ing them securely to each principal engaging in a data ex- 
change. In addition, session keys reduce the vulnerability of 
long-term principal keys because the latter are used less 
often and therefore are less susceptible to offline attacks. 

The conversation and session keys are generated as random 
numbers by the DCE security service and are not reused. 
These keys have typical lifetimes measured in minutes. 
Session keys are keys communicated lo principals in tickets, 
whereas conversation keys are established dynamically by 
the KPC run-titne environment to protect the data transmis- 
sion. Session keys are used in the establishment of commu- 
nication keys. 

Authentication Protocol 

A simplified illustration of the authentication protocol is 
shown in Fig. 2. The circled numbers in this section corre- 
spond to the circled numbers in Fig. 2. 

At the start of a user login Sequence the computer estab- 
lishes a session with the I >CE security service. The user's 
password is transformed into a secret key ' . The c lient 
system has a file containing a machine TGT and a machine 
session key. Knowledge about the machine session key and 
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Fig. 2. t ireatioti ofa ticket-granting ticker (TOT) via the tuLhenUcation protocol.. 



tin' user see-ret key is shared between the client system and 
the E)C'E serv er system (see keys a and l> in Fig. 2). 

The protocol used for authentication is known as the DCE 
tliird-party preauthentication protocol- The protocol stalls 
with the DCE security library requesting, on lieltalf ofa login 
utility, a conversation key and a machine TGT from I he DCE 
daemon, deed 2 . Deed provides the first conversation key 
and the machine TGT along with a copy of the conversation 
key encrypted with the machine session key 3 . The secu- 
rity library then generates a token containing a lime stamp 
and a second conversation key. The library encrypts that 



token twice: once with the key derived from lite user pass- 
word and once with 1 lie lirsl conversation key 4 . This en- 
crypted token is passed lo the DCE security server along 
wilh I he machine TGT and Ihe encrypted conversation key 
received from the deed process 5 . 

Upon receipt of the token and other items, the DCE security 
serv er decrypts Ihe lirsl conversation key using the machine 
session ke\ 6 . It then decrypts the token containing the 
time Stamp and the second conversation key using the first 
conv ersation key i . Next, the loken is decrypted using the 
user's secret key stored in Hie registry database j . If the 
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time sump is within acceptable limits, the DCE security 
server creates a token containing a TGT and a client session 
key 3 - The security" server passes the token back to the 
client encrypted with the second conversation key >o . The 
client decrypts the token, validates its content, and stores 
the TGT and the client session key in the login context for 
use in future requests for service tickets ® . 

At this point the user and the IK E security server are mutu- 
ally authenticated. Note that the user's secret key was never 
sent (in plain or ciphered format ) to the DCE security server. 
Proof that the user knows the correct passw-ord is verified 
by the fact that the time stamp is successfully decoded by 
the DCE Security server. 

Privilege Service. Tin- TC T described above (iocs not contain 
the information necessary for the advanced authorization 
mechanisms such as groups and ERAs. The privilege service 
provides this information by creating an EPAC and a privi- 
lege TGT, which contains the TGT and a seal I checksum) of 
the EPAC. 

When an authenticated RPC is attempted and a valid privi- 
lege TGT is not available, the privilege service is contacted 
by the security library'- First i he library obtains a service 
ticket for the privilege service iti a manner similar to what is 
described below, bul using a TGT instead of the privilege 
TGT. 

The privilege service then prepares the extended privilege 
attribute certificate, creates the privilege TGT. and commu- 
nicates it back to the client. Application servers will be able 
to request the EPAC through the RPC nm-time environment. 

Secure Communication. The authentication and key exchange 
protocol needed to establish a secure communication chan- 
nel between B client and its associated server is transparent 
to the application. The RPC and CSS API facilities and the 
I K'E security service library cooperate in establishing a se- 
cure communication channel. 

Fig. :i is a simplifiedt representation of the sequence of 
events for establishing a protected (JPG communication 
channel, assuming a valid privilege T< !T has already been 
established by the privilege service as described above. The 
circled numbers in Fig. -i correspond to the circled numbers 
in this section. First, the application client makes a request 
to the application server by calling an RPC stub j . 

Since the application client needs a service ticket to authen- 
ticate itself to the application server, the security library 
generates a request to gel a ticket and a conversation key 
from the security server. This results in the creation of a 
token containing the request for the ticket and the privilege 
TGT encrypted by the client session key learned during the 
login sequence. The token is sent to the key distribution 
Center ( KDC) which is in the security server i . 

The KDC decrypts and validates the request and then gener- 
ates a conversation key for use between the application cli- 
ent and the application server. It encrypts the conversation 
key and the authentication information (in the service 
ticket ) with the secret key it shares with the application 
Server S It attaches another copy of the conversation key 

t In particular, tlie conversation key is established in Utj steps than shown, and the protocol 
iinnlemenis aching so as not 10 require all steps lo be oiecnled eve/v time 



to the service ticket and encrypts the whole structure with 
the client session key * . This token is then sent to the ap- 
plication client system 5 . which decrypts it and leams the 
conversation key 6 . 

RPC then enc rypts the RPC request with the conversation 
key i and sends it to the application server. The application 
server learns the conversation key and checks the client s 
authenticity. To accomplish this, the application server 
sends a c hallenge, which Ls just a random number t . The 
client receives this challenge and replies by sending a token 
containing the encrypted challenge and the encrypted service 
ticket and conversation key obtained front the security 
server I . The server decrypts the ticket and obtains the 
client privileges and the conversation key "> . It decrypts the 
challenge with this conversation key 0 , and if it matches 
what is sent, the authentic ity of the client is assumed. It then 
proceeds to decrypt the request from the client t? . The client 
and server now share a secret conversation key. 

Additional Functionality 

Extended Registry Attributes 

The DCE registry' contains principal account data in a well- 
defined format (i.e., a static schema). Every account record 
contains the same number and types of data fields, all tar- 
geted to meet the requirements of either DCE security or 

I MX platform security. To support integration with other 
platforms and security systems, the DCE registry needed a 
way to store non-DCE or non-UNIX security data for princi- 
pals. To meet this need, the DCE registry was augmented 
with a dynamic schema facility called the extended registry 
attribute ( BRA) facility, which supports the definition of 
new types of data fields called attribute types tuiil the assign- 
ment of specific values for those attribute types lo principals 
and other registry objects like groups and organizations. 

In the ERA schema, administrators define new attribute 
types by specifying a unique attribute name (e.g., X.500_Distin- 
guistietLName). the appropriate dala type (e.g.. string), the 
type of registry object (e.g., principal ) that supports niirib- 

II les of this type, and oilier related information. • )nce the 
attribute type has been defined ill tfefi schema, an adminis- 
trator can attach an instance of that att ribute type to any 
registry object that supports it For example, an attribute 
instance whose type Ls X500_Distinguished_Name and whose 
value is /C=US/o=HP/OU=OSSD/G=JOE/S=KING could be attached 
to the principal Joe.tt From then on applications that re- 
quire knowledge of Joe's X.50U distinguished name could 
query the registry for that attribute type on the principal 
Joe. 

In some cases, attribute values of a certain type are more 
appropriately created and maintained outside of the DCE 
registry. These could include attributes that arc- already main- 
tained in a preexisting legacy database or attributes whose 
values differ depending on discriminating factors such as time 
of day oroperation to be invoked. The ERA trigger facility 
supports cases such as these by providing an automatic trig- 
ger (or callout 1 to a remote trigger server that maintains the 
at tributes of interest. For example, if the registry receives a 

1 1 See thr) article on page ?3 tor an explanation ol the fields in ihis stung 



© Copr. 1949-1998 Hewlett-Packard Co. 



December 1996 Hewlett ■Packard Journal 45 



Application Client System 



Application Client 





RPC Stubs 


DCE Library 




RPC Q 











Request 
PTGT 



Challenge 



PTGT 



Security Server System 

Authentication 
Server 



r 



Service Ticket 




C 


Challenge 


0 




Service Ticket 


Q 



® 



® 



® 



Request 
PTGT 




Service Ticket 



® 



0-r 



© 



Application Server System 
Application Server 

DCE Library 



RPC 



® 



® 



Challenge 



® 



Challenge 



Service Ticket 

0-w 



® 



Key Table 
servl- 



® 



^f^^ Client Session Key 
O^ff Server Secret Key 

O^P Conversation Key 
0^1 Generated Keys 
PTGT = Privilege TGT 



Fig. 3. Setting up a secure communication between a client and server. 

query for a particular attribute type that is marked as a 
trigger, the registry forwards the query to a preconfigured 
trigger server. The server will return the appropriate attrib- 
ute value to the registry, which will then respond to the orig- 
inal query wilh this value. A query for a trigger attribute may 
include input data required by the trigger server to deter- 
mine the appropriate attribute value to return. Trigger serv- 
ers are no! provided its part of the DCE package; they are 
provided by third-party integrators of security systems. The 
ERA trigger facility provides the rules, interfaces, and mech- 
anisms for integrating trigger servers with the DCE security 
service. 

Some application servers need to make decisions, especially 
authorization decisions, based on the calling principal's 
attribute values. The DCE privilege service supports this by 
providing a way for applications to request that specific 
attributes be included in a principal's EPAC As described 
earlier in the "Identification and Authentication" section, the 
RPC run-time environment supports queries for obtaining 



the calling principal's EPAC. This enables application serv- 
ers to base decisions on the caller's attribute values and the 
identity and groupset information in the EPAC. 

Delegation 

In a distributed environment, an application server process- 
ing a client request may have to make a request on its own 
to another server to complete the client request. We will call 
I he application server with the request an intermediate 
server. The identity repotted by the intermediate server to 
the saver it contacts can be either its own identity or the 
identity of the client that made the original request. This 
latter case is called delegation because the intermediate 
server acts as a delegate of the client. A delegation chain is 
built as intermediate servers call other intermediate servers." 

For delegation to be possible, the client has to enable this 
feature explicitly. Two types of delegation are available: 
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Traced delegation in which the identity and privileges of 
each intermediary are kept and can be used for access 
control 

Impersonation in which only the originator's identity and 
privileges are carried in the extended privilege attribute 
certificate. 

ACLs have been extended to support delegation, making it 
possible to grant access based not only on the originator of 
the request, but also on the intermediaries. This allows ad- 
ministrators to grant access to serv ers acting as delegates 
on behalf of particular originators without granting access 
to the same servers operating on their own behalf. 

Compatibility with Kerberos 

The authentication service provided in the DCE security is 
derived from Kerberos version 5.' The protocol used be- 
tween a client and server using the DCE security service is 
the native Kerberos protocol and has been adapted for RPC 
transport. 

DCE security supports Kerberos version 5 clients (e.g., a 
telnet, or a terminal server that uses Kerberos version 5). 
This removes the need to manage a separate Kerberos realm 
because DCE security supports the registration and authen- 
tication of Kerberos principals. 

DCE security also provides an API that can be used to pro- 
mote Kerberos credentials t hai have been forwarded to a 
DCE client into full DCE credentials. Full DCE credentials 
represent an authenticated DCE principal, thereby enabling 
use of DCE services. 

Auditing 

DCE offers an auditing service that is pail of DCE security. 
The DCE security and time services use auditing to record 
security-relevant events like account creation, ticket grant- 
ing, and system time changes. 

DCE auditing is com rolled by Hie DCE control program, with 
which DCE administrators can select the events to audit anil 
control the operation of the audit subsystem. 

Authenticated RPC 

The DCE remote procedure call (RPC) facility is described 
in more detail In the article on page 6; The RPC facility is 
integrated with I he IK E security service and is referred to 
as the authenlicaied RPC run-lime environment. 

When an application client wants to make a protected re- 
mote call, it calls the authenlicaied RPC run-time environ- 
ment lo select: 

The authentication service, which can be either no authenti- 
cation orsccrei key authentication 

The protection level, which specifies whether authenlica- 
lion should occur only at the beginning of an RPC session or 
at each message or packet and whether message data 
should be integrity or confidentially protected 
The authorization service, which can be name-based, in 
w hich case only the name of the caller is known to the 
server, or privilege-based, in which case all the privileges of 
the client, in the form of an EPAI '. are made available lo Ihe 
server for authorization. 



The application developer can trade off the resources con- 
sumed by an application with the level of security required. 

Generic Security Service API 

The GSS API improves application portability by reducing 
security-mechanism-specific code. It also provides transport 
independence since the data protection is not tied to a par- 
ticular communication mechanism (e.g., DCE RPC). GSS 
API calls are used to authenticate and establish a security 
context between communicating peers and to protect 
blocks of data crypt ographically for transmission between 
them. The data protection includes data origin certification, 
integrity, and optionally, confidentiality. 

The GSS API supports many different underlying security 
mechanisms. The GSS API implementation provided with 
DCE supports both the DCE and the Kerberos version 5 
mechanisms. 

Security Run-Time Environment 

Applications can access security functions directly through 
the security library, which is part of the DCE library on the 
HP-l'X operating system. The security library provides APIs 
to make access decisions based on ACLs, manage key tallies, 
query and update registry data, login and establish creden- 
tials, and so on. 

System administrators and users can use a series of com- 
mands to administer the security service or manage their 
[QCal security resources such as credentials, ACLs, or key 
tables. Most of the administrative commands are part of Ihe 
DCE control program. 

Multicell Configurations 

Li large enterprise networks, it is often impractical or unde- 
sirable to configure a single cell. For this reason. DCE fea- 
tures intercell communication mechanisms. See the article 
on page fi for a brief description of cells. 

The DCE security service is an actor in this intercell envi- 
ronment. Through a mechanism of key exchange, a relation- 
ship of trust can be established between two cells. When an 
application clienl wants to communicate with a server in a 
foreign cell, it must obtain a service tickel for thai server. To 
do so. the DCE security service automatically generates a 
foreign privilege TfiT, which contains the privilege informa- 
tion about the principal (application client ) in its local cell 
encrypted using the foreign cell's keys. This key. shared be- 
tween the two cells, is used to authenticate and secure this 
protocol. The DCE security service then proceeds to get a 
service ticket to the foreign server by Contacting the foreign 
authentication service as it would do for the local cell by 
using the foreign privilege TGT instead of the privilege TGT 
used in the example given earlier. 

ACLs support the intercell operations by allowing foreign 
users, groups, and others to be granted permissions. 

High Availability 

The DCE security service is an essential piece of the distrib- 
uted computing environment. Thus, the security service 
must slay operational around Ihe clock even when systems 
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are down or network connections arc unavailable, which 
could happen frequently in wide area network environments. 

For this purpose, the DC'E security service features a server 
replication mechanism. The master replica is the only one 
that can accept requests for updates such as password 
changes or account modifications. These modifications are 
sent securely to slave replicas, which contain a duplicate 
image of the legist r\ database, but support only query, not 
update operations. The use of slave replicas improves per- 
formance in busy environments since additional IKK secu- 
rity servers are available to process queries and requests for 
secure communication. 

The DC'E security service administrative commands allow 
the role of master to be moved between replicas. In case the 
machine hosting the master is not available for some time, 
the administrator can force a slave to become the master. 

In the rare case in which no network connection is available 
to reach a l)( 'E security server, the DC'E security login client 
will use a local cache of credentials that have been granted 
recently to perform authentication. However, the credentials 
usually cannot be used to obtain service tickets. 

System Security Requirements 

The use of the DCE security service alone does not guarantee 
a secure distributed computing environment The security 
Service relies on protection features offered by the local 
operating system to store its data and credentials. 

The systems hosting a UCE security server must be pro- 
tected from unauthorized access. They should be placed in a 
secure area, such as a locked room, and be given the highest 
security considerations. In particular, certain network ser- 
vices should be disabled and a limited number of users 
should be given access. This security is required because the 
DC'E security server holds the keys to all the principals in 
the enterprise. 

The systems hosting the application servers should also be 
managed with care, mainly to protect the enterprise data, 
which is often not protected by the DC'E security service. 

Application clients do not need such stringent management 
guidelines. On multiuser systems, the user environment 
should be partitioned so that one user cannot steal the cre- 
dentials of another active user, which could be done by 
reading the other users credential files. 

The DC'E security service does not guarantee that there are 
no undetected intruders in the system. It offers no protection 
if the program used for login has been modified to steal the 
password, saving it for future retrieval by an intruder. 



If a system other than one hosting a DC'E security server is 
compromised, only the application servers residing on that 
system and the users who performed a login on that system 
during the period of compromise are affected. The overall 
distributed computing environment protected by the DC'E 
security service is not affected. This is because the keys are 
known only by the owner (server, machine, or application) 
and the DC'E security servers, and they are never communi- 
cated to a third party. 
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An Evolution of DCE Authorization 
Services 



One of The strengths of the Open Software Foundation's Distributed 
Computing Environment is that it allows developers to consider 
authentication, authorization, privacy, and integrity early in the design of a 
client/server application. The HP implementation evolves what DCE offers 
to make it easier for server developers to use. 

by Deborah L. Caswell 



In I he i tpen Software Foundation's Distributed Computing 
Env ironment (DCE). 1 - services are provided by server pro- 
cesses. They are accessed on behalf of users by client pro- 
cesses often residing on a different computer. Servers need 
a way to ascertain whether or not the user has a right to 
Obtain the service requested. For example, a banking service 
accessed through an automated teller machine has to have a 
way to know whether the requester Ls allowed to withdraw 
money from the account. A medical patient record service 
has to be able to know both who you are and what rights 
you should have with respect to a patient's record. A policy 
can be implemented such that only the patient or the legal 
guardian of the patient can read the record, but doctors and 
nurses can have read and write access to the record. 

The process of determining whether or not a user has per- 
mission to perform an operation is called authorization. It is 
common to separate the authorization policy from the au- 
thorization mechanism. Authorization policy dictates who 
has permission to perform which operations on which ob- 
jects The mechanism is the general-purpose ''fide that en- 
forces whalevei policy is specified. In DCE. the encoding of 
the authorization policy is stored in an access control list 
( ACL). Every object that is managed by a server such as a 
bank account or a patient record has associated with it an 
ACL that dictates which clients can invoke each operation 
defined for the object. 

For example, to encode the policy that the owner of the 
bank account can deposit and withdraw money from the 
account and change the mailing address on the account, bul 



only a bank teller may close the account, an ACL on a bank 
account owned by client Mary might look like: 

user:Mary:DWM 
group:teller.C 

where D stands for permission to deposit, W for permission 
to withdraw. M for permission to change the mailing address, 
and C for permission to close the account. 

Each application is free to define and name its own set of 
permissions. The D. W. and C permissions used in the exam- 
ple above are not used by every server. An application in 
which the D (deposit ) permission makes sense could choose 
to nam il as the V permission. Also, many applications 
will not have a deposit operation at all. Therefore, the inter- 
pretation of an ACL depends on the set of permLssioas de- 
fined by the server that uses it. 

The first pan of this paper describes the specific -ations and 
authorization mechanisms (code) offered in DCE thai sup- 
port the development of authorization services. The second 
part describes our efforts to supplement what DCE offers to 
make it easier for the server developer to use authorization 
services. The ACL functionality described here pertains to 
DCE releases before GBP DCE LI and HP DCE 1.4. 

Authorization Based on Access Control Lists 

Fig. 1 shows the client/server modules required for an ACL 
authorization scheme used in a hypothetical bank applica- 
tion thai was implemented using DCE. To understand the 
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interactions between these modules consider the following 
scenario. Jane makes a request to withdraw U.S. S 100.00 
from her account number 1234. The application interface 
passes this information to the ACL manager asking for an 
aulliorization decision. The ACL manager retrieves the au- 
thorization policy for account 123 1 from the ACL database 
and applies the policy to derive an answer. If Jane is autho- 
rized, the machine dispenses the money. 

When Jane's account is first set up. a bank employee would 
use an administration tool (from the management process in 
Fig. 1) to give Jane permission to withdraw money from 
account 1234. The editing interface enables the ACL manager 
to change the policy. The ACL manager changes a policy by 
retrieving the current policy, modifying it, and writing it 
back to the ACL database. 

ACL Database. A server that needs to authorize requests must 
have a way to store and retrieve the ACLs that describe the 
access rights to the objects the server manages. One appli- 
cation might want to store ACLs with the objects they pro- 
tect and another might want a separate ACL database. 
Depending on the number of objects protected and access 
patterns, different database implementations would be opti- 
mal. For this reason, the requirements for an ACL storage 
system are likely to be very dependent on the type of 
application. 

An Authorization Decision. When an application client makes 
a request of the application server, control is given to the 
manager routine that implements the desired operation. The 
manager routine needs to know what set of permissions or 
access rights the client must possess before servicing the 
request. 

The manager routine must supply the Client's identity (Jane), 
the name of the protected object (Account 1234). and the 
desired permissions (withdraw) to a routine that executes 
the standard ACL authorization algorithm. If the routine 
returns a positiv e result, the Server will grant the client's 
request (dispense U.S. $100). Note that the authorization 
system depends on the validity of the client's identity. 
Authentication is a necessary prerequisite for authorization 
to be meaningful. 

Standard Interface for Editing. Without a standard way of ad- 
ministering ACLs, each server developer would hav e to pro- 
vide an ACL administration tool, and DCE administrators 
would have to learn a different tool for each server that uses 
authorization. To avoid that problem, a standard ACL editing 
interface is defined so that the same tool can interact wiih 
any service that implements the standard interface. 

What DCE Provides 

To meet the requirements for the ACL management scheme 
mentioned above, DCE provides code to support ACL 
management for some requirements and simply defines a 
standard interface without providing any code for other 
requirements. Fig. 2 shows the main components that pro- 
vide DCE ACL support within the server executable. 

Unforgeable Identities. DCE provides the run-time RPC (re- 
mote procedure call ) mechanism, which provides the server 
process with information about the client making a request. 
Because of the authentication services provided in DCE. the 
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client's identity is unforgeable so I hat the server need not 
worry about an impostor. 

ACL Database. DCE suggests an interface to an ACL storage 
and retrieval subsystem called sec_acLrngr. This interlace is 
used within the server, and therefore is not mandatory or 
enforceable. DCE currently does not provide an implemen- 
tation of this interface for use by application developers. 
Furthermore, it does not contain operations for adding and 
deleting ACLs. so even if the sec_acl_mgr interface is used, it 
would have to be supplemented by other ACL database 
access operations. 

Authorization Decisions. DCE specifies a standard way of 
reaching an authorization decision given a client's identity, 
desired operation, and authorization policy encoding. The 
OSF DCE 1.0 distribution for application developers does 
not supply an implementation of this algorithm, requiting 
the server developer to write the authorization algorithm. 

Standard Editing Interface. DCE provides a tool called acl_edit 
that an administrator can use to change the authorization 
policy used by any server that implements the standard rdacl 
interface even though each serv er might use a different set 
of permissions. 

DCE defines the standard rdacl interface responsible for 
enabling modification of the authorization policy. The rdacl 
interface is used by acl_edit to access and modify ACL infor- 
mation. DCE does not provide an implementation of the rdacl 
interface. Without additional help from other sources, each 
server developer has to write rdacl routines that call the ACL 
database access routines. Servers that implement the rdacl 
interface can be administered by any client that uses the 
standard interface including the acl_edit tool mentioned 
above. 
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The rdacl interface does not support adding and deleting 
ACLs: it only addresses editing existing ACLs. For that 
reason, an ACL storage subsystem must he designed and 
implemented for an application that supports adding, 
modifying, retrieving, and deleting ACLs. 

The rdacl operations listed below are described in the DCE 
reference manual. * They are listed hen- to give an idea of 
the size and functionality of the interface. 
fdacl_get_access: lists the permissions granted to a principal 
to operate on a particular object 

rdacl_get_manager_types: gets the list of databases in which the 
ACL resides 

rdacl_get_pnntstring: gets the user description for each 
permission 

rdacl_get_referral: gels a reference to the primary update site 
rdacljookup: gets the ACL for an object 
rdacLreplace: replaces the ACL for an object 
rdacl_test_access: returns true if the principal is authorized to 
perform the specified operation on an object 
rdacl_test_access_on_behalf: returns true if both the caller and 
a specified third-party principal are authorized to perform 
the specified operation on an object. 

An implementation of these operations has to call Ihe re- 
trieve and modify operations of the ACL storage subsystem, 
invoke the authorization decision routine, and describe the 
permissions that are used in the ACLs for the particular 
implementation. 

Component Relationships. Some of the boxes in Fig. 2 
represent code that is automatically generated from Ihe 
interface description, and other boxes represent code that 
must be supplied by server developers. 

The modules on the right side of the block diagram In Fig. 2 
represent Ihe application-specific interfaces and code. The 
application interface stub is the code generated by the Inier- 
face Definition Language (IDL) compiler when given the 
application interface files. For example, if we have a bank 
account server, the application interface stubs would re- 
ceive the call and direct it to the application manager. The 
application managers are the modules thai implement Ihe 
application server functionality. In our bank example, this is 
the code that implements the deposit and wiihdrawal 
operations. 

( )n the left side of Fig. 2 is Ihe code that is specific lo ACL 
ntanagemeni of the DCE Standard rdacl interface. The rdaclif 
(rdacl interface file) server stubs are generated by running 
the IDL compiler over Ihe rdaclif idl file which is delivered 
with the DCE product, The rdacl routines implement the op- 
erations defined in the rdaci interface. The bottom of Fig. 2 

shows the ACL storage and retrieval code. The rdacl routines 
make calls lo the storage layer either to gel ihe ACLs thai 
will be sent over Ihe wire to a requesting client or to replace 
a new ACL received from an ACL administration tool. The 
database access routines must also implement the standard 
ACL clucking authorization algorithm and a routine to com- 
pute the effective permissions of a client with respect to a 
specific object. The application managers call the database 
access layer lo gel an authorization decision. For example, 
Ihe code thai implements the withdrawal operation needs to 
first make sure that the client making the request is autho- 
rized lo withdraw money from a particular account. 



Although they do not interact directly with each other, the 
application manager routines and rdacl routines coexist 
within the same process and call common ACL manager 
routines. 

Summary 

DCE supjiorts a server process's ability to make an autho- 
rization decision in several ways, but as shown in Fig. 2. 
there is a lot of code left for the server developer to write 
Some of the required code, such as Ihe authorization deci- 
sion routine, can be reused in other applications because it 
is application independent. Other code, such as the storage 
subsystem, is more application-specific and might have to 
be developed for each new service. 

Help for the Server Developer 

This section describes three evolutionary' steps that we look 
to supplement DCE s authorization support. The approach 
we took to each step is not novel. Each approach has value 
by itself in addition lo being a stepping stone to a more 
sophisticated approach. 

Note that although the outputs from each of these steps did 
not directly become products, they did form the basis for HP 
Object-Oriented DCE (HP OODCE). HP OODCE is briefly 
described later in this article and completely described in 
Ihe article on page 55. 

Sample Applications. The first step was simply to provide an 
example of server code that performs ACL management. 
The application acLmanager is one of a set of sample applica- 
tions written to demonstrate the use of various DCE facili- 
ties. These sample applications are a valuable learning tool 
and are also useful for culling and pasting working code into 
a real-world application. 

The acLmanager is based on the ACL manager reference im- 
plementation distributed with DCE source code. The sample 
application uses a static table of ACLs, and there is no oper- 
ation for adding or deleting ACLs and no general storage 
manager. Howev er. acl_edit can interact wilh this primitive 
A( I. manager lo view or modify the ACL for one of these 

sialic objects 

The acLmanager includes a description of how to tailor the 
code to one's own application server and provides more 
background on how ACL management works lhan is avail- 
able in the DCE manual set. 

Another sample application, the phone database, demon- 
si rales ihe use of an ACL manager inside an application. 
This more complex sample application demonstrates how 
application interfaces and Ihe ACL management interface 
coexist within ihe same server and how they interact The 
phone database application uses an in-memory binary tree 
storage facility with a simple checkpoint facility for commit- 
ting changes to stable storage. 'Hie persistent representation 
of ACLs can be modified by an editor for bulk input. At 
startup, ihe server parses and interprets this file. 

As mentioned before, in addition to being a valuable learn- 
ing tool. Ihe sample applications provide reuse of code and 
ideas at the source-code level. 

Common ACL Management Module Interface. Culling a sample 
application and pasting it into a new application wilh an 
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understanding of how it needs to lit' modified is surely bet- 
ter titan stalling from scratch. Reuse through a code library 
iS heller yet. The problem was how to provide a single li- 
brary for ACL management when so much of it is applica- 
tion-specific. There is so much flexibility in how ACLs are 
managed. We wondered if it w ere possible to anticipate 
what most developers w ould need and if we would be able 
to satisfy those needs by creating a general-purpose library. 

The first task w as to partition the aspects of ACL manage- 
ment into those that are applicai ion-specific and those that 
am application independent The application independent 
portion would be provided as library routines. Our approach 
in the application-specific portions was threefold: 

• Limit the flexibility by providing routines that would be suf- 
ficient for most developers. For example, although DCE 
allows a seiTer to implement mure than 32 permissions, 
limiting support to 32 or less simplified the design 
considerably. 

• Parameterize tontines such that their behavior can be deter- 
mined when the library is initialized at startup. For exam- 
ple, each application defines its own set of permissions. A 
table of permissions can be downloaded into the library 
rather than hard-coded into the library routines. 

• Identify a well-defined interface to the storage and retrieval 
routines. As mentioned earlier, the storage requirements are 
the one aspect of ACL management that will vary the most 
among applications. By partitioning the functionality in this 
way. customers with special storage needs can write their 
own ACL storage management, and provided that they con- 
form to the published interface guidelines, would still be 
able to use I he library for other ACL management functions. 

Fig. 3 shows a different view of the ACL components de- 
picted in Fig. 2. The application server component is not 
called out separately in Fig. 2. The server initialization code 
(server.c) is typically located in this component. The applica- 
tion server also contains the code that directs the DCE run- 
time code to start listening for incoming client requests. 

The application manager component in Fig. 3 contains the 
same functionality as the application manager component 
shown in Fig. 2. 

The ACL manager component in Fig. 3 represents the code 
needed to support the rdacl interface, the ACL checking algo- 
rithm, the computing of effective permissions, and other 
general utilities. Basically, the ACL manager contains all the 
ACL code that is independent of how an ACL is stored 



within a database. It also encapsulates the implementation 
of the ACL structure itself. In other words, il I he data struc- 
ture that represents an ACL were to change, only the ACL 
manager component would need to be rew ritten to accom- 
modate the changes. 

The ACL storage manager contains the A< L database access 
routines and the ACL database. The ACL storage manager 
can manage ACL storage in memory, on disk, or a hybrid of 
the two. 

The circled numbers in Fig. 3 correspond to the following 
interactions between ACL manager components. 

1. The application server must call the ACL manager to ini- 
tialize its internal data structures and to download applica- 
tion-specific information such as permission print strings 
and reference monitor callback functions. The reference 
monitor implements a general security policy that screens 
incoming requests based on the client's identity and the au- 
thentication or authorization policies it is using. The mom- 
tor does not base an authorization decision on the requested 
operation or the target object. The ACL manager performs 
that job. A default reference monitor is provided by the A< !L 
manager. If an application has its own reference monitor, it 
will be invoked instead of the default monitor supplied with 
the ACL manager. 

2. The application server must call the ACL storage manager 
to allow it to initialize itself. The initialization calls performed 
by the application server are only done once when the whole 
system is initialized. 

3. The application manager calls the ACL manager to per- 
form an authorization decision or to invoke a general ACL 
utility 

4. The application manager calls the ACL storage manager 
to add a new ACL to the database or to delete an old A< I. 
from the database. 

5. The ACL manager calls the ACL storage manager to trans- 
fer an ACL to or from the database in response to rdacl 
reque8tS coining from acl_edit. 

(i. The A( L storage manager calls the ACL manager utility 
routines to manipulate ACL data structures. ( Ine manipula- 
tion operation involves converting permissions from human 
readable form into a bitmap and vice versa. 
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7. The AI L manager must make a callback lo an application- 
specific reference monitor routine to screen an incoming 
rdaci request according to the application's general security 
policy. 

The goal for the common AC L management module interface 
was to explore appropriate programmatic inierfaces. Our 
implementation was a proof of the concept for the design 
and was not intended to he the besi ACL manager package. 
The implementation provided the same functionality as the 
sample application except that it used an in-memory binary 
tree to allow applications to add ACLs at run time. The main 
contribution of the common AC L management module inter- 
face from an application developers standpoint is the ability 
to link widi a genentl-ptirp"S'' library rather than cutting and 
pasting source code. The application developer can use 
higher-level interfaces for creating ACLs and get authoriza- 
tion decisions without having to understand and Write the 
Underlying mechanism. 

Although the common ACL management module interface 
was never sold as an HP product, it was useful in several 
ways. First, we learned a great deal about ACL management 
and what developers would want to be able to do with it. 
Second, we used the modules in an internal DCE training 
class that allowed us to teac h ACL management concepts 
and have the students add ACL management to an applica- 
tion they developed during a twoto-three-hnur laboratory 
exercise. The common ACL management module interface 
allowed the students to spend their lab time reinforcing the 
concepts presented in the lecture rather than gelling bogged 
down in writinga lot of supporting code just to make their 
application work. The experiences of the class reinforced 
our belief that it is possible lo support application develop- 
ers in the creation of ACL management fund tonality without 
every developer having to understand all of the complicated 
details of ACL management that are DCF.-prescribcd but not 
applicat ion-specific. 

'Hie version of IX" E provided by < (SF only supports ( ' pro- 
grammatic interfaces. It made sense to implement the com- 
mon ACL management modules in C for two reasons: 
Since we wen' layering on lop of DCE, it was more conve- 
nient to use | he supported language. 
We expected that users of the common ACL management 
modules would also be programming in (', and so would 
want C interfaces lo the common A< I. management module 
Interface library. 

However, there is growing interest in C + + inierfaces to IX'E 
as well as support for object-oriented programming. In 
response to that need, a C++ class library for IX'E called 
(>< IDCE (object-oriented DCE) has been developed. 

IIP OOIH'E: A C++ Class Library for DCE 

The common management module interface acted as a 
springboard for design and implementation of the C++ ACL 
management classes which are pail of HP's OODCE 
product Since it is much easier to create abstract interface 
definitions in C++ than in C. these DCE A' I. management 
classes make il easier to provide access control within a 
DCE server. Application dev elopers can reimplement spe- 
cific classes lo customize the At I, manager lo 111 llicil 
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Fig. 4. HP 01 IDCE ACL management class interrelationships. 

needs. The classes supplied with OODCE and their interrela- 
tionships 8K shown in Fig. 4. The classes shown in Fig. 4 
represent further modularization of the ACL manager and 
ACL storage manager components shown in Fig. -I. 

Class Descriptions. The DCEAclMgr class implements the rdaci 
interface for use by the acLedit tool and other management 
tools, There is one instance of an DCEAclMgr per applicat ion 
server. The DCEAclStorageManager manages all At 1. databases 
for this server. The DCEAclStorageManager is responsible for 
finding the database in which the ACL is stored and return- 
ing a handle to that database. Programs invoke the OCEAcl- 
StorageManager interface to create or register a new ACL 
database and lo access existing ones. 

The DCEAclDB class defines the interface to an A( 'L database. 
An ACL database may define multiple 32-bil words of per- 
missions. The Interpretation of the permission bits is stored 
in a DCEAclSchema object, and each database has exactly one 
DCEAclSchema associated With it. 

The DCEAcI class defines an interface for accessing DCE A< I. 
informal ion. In addition lo the DCE A< I. information, the 
DCEAcI class contains informal ion about the database in which 
il resides, the owner and group of the protected object, and 

other informal ion thai is needed by an Implementation. The 

DCEAcl's stale is read-only. The DCEModifyableAcI class is a 

modifiable version of the dceaci class. 

Using the OODCE ACL Management Classes. The application 
server invokes a simple macro thai initializes the ACL sys- 
tem. OODCE, by default, handles all the details of making 
the rdaci interface ready to be invoked by remote clients. 
This includes registering the interface with the lilt ' run time 
routines so lhal an incoming request for thai interface is 
receiv ed and ensuring that the coned entry point for the 
rdaci routines is invoked. The application server also handles 
exporting location Information to the endpoiro 1 mapperl and 
CDS (cell directory service) database so lhal clients can find 
the server's ACL management interface. That is the only 
required involvement of tin- application server. However, the 
application server may create DCEAclDb objects that can be 
shared across manager objects. These databases iiiusl be 
registered with the DCEAclStorageManager, 

TM mapper maintains a lisl ol interlaces anil Hie corresponding pnil mimlieis where services 
ol ihn interlaces sie listnninii 
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Application managers create new ACL objects by first re- 
questing the DCEAclDb object to create a DCEModiiyableAcI ob- 
ject and adding ACL entries to it. When done, the DCEModify- 
ableAcI object is committed (added) to the database. To get 
an authorization decision, an application manager retrieves 
an ACL object from the database and interacts with il to get 
an authorization decision. 

Overall, it is easier for the application developer to use the 
OODC'E ACL manager classes than any of the previous 
solutions. Many of the routine tasks are done by default by 
the library, but they can be overridden if lln-n- are special 
Circumstances. The ACL management objects are written to 
the abstract class definition so tliat users can provide their 
own implementations Of DCEAclDb. OCEAcl. and DCEModifyable- 
Acl classes and have them plug into the rest of the system. 

A DCEAclDb implementation encapsulates the database ac- 
cess. This allows the flexibility of storing ACLs either with 
the objects managed by the server or in some other data- 
base. Any commercial database product can be used. The 
server developer need only implement DCEAclDb so that it 
Conforms to the abstract interface and makes the calls to 
the commercial database of choice. 

The DCEModifyableAcI class allows for line-grained editing. The 
rdacl interface only supports the atomic replacement of an 
entire ACL. whereas the DCEModifyableAcI design supports 
changing individual elements within an ACL. 

IIP OODCE ACL objects are more general-purpose than the 
common ACL management module interface described ear- 
lier because the abstract class design of HP OODCE accom- 
modates more features. Its design supports more than 32 
permissions, anil registration of the rdacl interface with CDS 
and the endpoinl mapper is automatic and transparent to 
the server developer. 



Current Status HP ( )( tl)( E is now a product. It includes de- 
fault implementations for all the classes, but we expect that 
customers will write their own implementations of DCEAclDb 
and possibly or DCEAcI and DCEModifyableAcI. There is still 
much lo learn about what distributed application developers 
really need from an ACL management package, but with the 
HP OODCE library as a product, we have more Opportunity 
to get feedback. HP OODCE is described in more detail in 
the article on page 55. 
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An Object-Oriented Application 
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Using the Interface Definition Language compiler and the C++ class 
library, the HP OODCE product provides objects and abstractions that 
support the DCE model and facilitate the development of object-oriented 
distributed applications. 

by Mihaela C. Gittler, Michael Z. Luo, and Luis M. Maldonado 



HP's Object-Oriented DCE (IIP OODCE) provides a library 
Of framework and utility C++ classes that hide DCE pro- 
grammatic complexity from developers and provide auto- 
matic default behavior to ease the dev elopment of distrib- 
uted applications. The default behavior is also a great help 
in shortening application development time. HP OODCE 
offers flexibility by allowing developers to use subclassing 
and customized implementation. Fig. 1 shows the product 
structure for HP OODCE. 

HP OODCE allows clients to view remote objects as C++ 
objects and to access member functions and receive resulls 
without making explicit remote procedure calls ( RPCs). 
Also, applications can communicate with each other using 
interfaces specified by the Interface Definition Language 
(IDL). Finally, IIP OODCE uses the C++ class library and the 
IDL compiler (idl++) to create an object-oriented program- 
ming environment that supports HPC-based communications, 
client/server classes. POSIX threads, and access to the DCE 
naming and security services. 
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idl++-Generated Classes 

The idl++ compiler takes an IDL specification like the one 
shown in Fig. 2 and generates the C++ classes shown in 
Fig. 3. The idl++ compiler also generates the header file and 
stubs normally produced by the DCE IDL compiler. 

The concrete client class* describes the client proxy object 
that accesses remote C++ objects implemented by the 
server. The proxy object gives the client the impression that 
the instantiation of a particular server object is executing 
locally. Fig. J shows an example of a client proxy class dec- 
laration for an interface to the Sleep function, which is re- 
sponsible for putting a process to sleep. This class contains 
multiple constructors that, when called, locate the compat- 
ible manager (server) objects based on location information 
and the I I ID ( universal unique identifier) supplied as argu- 
ments to the constructors. 

The abstract server class in Fig. 3 provides declarations for 
member functions denned in the IDL specification that 
correspond to remote operations that can be accessed by 
the chenl prosy object. The default concrete server class 
declares the member functions specified in Ihe abstract 
class. The functions must be Implemented by the application 
developer, Fig. 6 shows the abstract and concrete server 
manager declarations for the Sleep function. 

The entry point vector contains entry points for each remote 
procedure defined in the IDL specification. 

IIP OODCE Server and Client Classes 

The server code that interacts with Ihe DCE subsystems is 
embodied in the DCEServer class. An instance of the DCEServet 
class, called theServer. manages Ihe remote objects that are 
exported by Ihe D< E server application. These objects arc 



//loo.idl 

[uuid(OOFCDD70 7DCB 11CB-BDDD-080O0920E4CCI. 
versiond 0)1 
interlace sleeper 

( 

lidempotentl void Sleep 
I 

1 



in] handle t h 
ml long timel, 



Fig. 1. Ill' i lOI.K'K pi'Milm l structure. 



Fin. 2. IDL specification for the Interface Sleep 

' See glossary nn page 60 lot a Duel description ol the C" temnnologv used in this article 
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Fig. 3. Tin fill a ' realed afl.-i an 
IDL specification is processed by 

the uii++ compiler. 



instances of the concrete server manager classes and each 
has a DCE LT'ID. Tliere is one DCEServer instance per DCE 
rpc_serverjisten call (currently per UNIX " process), which 
starts the server's run-time listening for incoming RPC re- 
quests. DCEServer has member functions that establish poli- 
cies such as object registration with I he RPC run-time pro- 
cess or the naming service and setting security preferences. 
' ihject registration lakes place whenever the DCEServer class 
met In id RegisterObject is called. Fig. (> shows the server main 
program for the Sleep object and the implementation of the 
Sleep function. 

In IIP OODCE, server objects are accessed via a client ob- 
ject (see Fig. 7). The client RPC request specifies a binding 
handle that locates the interface and the DCE object I 'I'll). 
The entry point vector code locates the correct instance of 
the requested manager Object Fig. 8 shows the HP OODCE 
client/server run-time organization. 

The idl++-generated client proxy class has methods corre- 
sponding to the operations defined in the IDL specification. 
Icll++ provides an implementation of the client proxy object 
methods. These methods locate the server and call the cor- 
responding C ++ stub generated by the idl++ compiler. The 
proxy implementation handles refunding, seis security pref- 
erences, and maps DCE exceptions returned by RPC into 
C++ exceptions (described below). 



class sleeper 1 0 : public DCEInlerface ( 
public: 

sleeper, 1 0(OCEUuid& to = NullUuid): 

OCEInterfacetsleeper vl _0_cjlspec, to) 1 ) 
sleeper_1_0(rpc_binding_handle t bh. DCEUuidS to = NullUuidl : 

DCEInterfacelsleepervl JLcJfspec, bh. to) { ) 
sleepeM_0(rpc_binding vector !" bvecl : 

DCEInterlace(sleeper_vl_0_cjfspec. bvec)( 1 
sleeper_1_0(unsigned char" name. 

unsigned32 syntax = rpc c ns syntax^default. 
DCEUuidS lo = NullUuidl: 

DCEInterface(sleeper_v1 0 c ilspec, na,e, syntax, to) ( ) 
sleeper 1 Olunsigned char" netaddr, 

unsigned char* protseq, DCEUuidS to = NullUuid) : 

DCEInlerlace(sleeper_v1_0_c . ifspec, netaddr. protseq. to) ( ) 
sleeper 1 OlDCEObjRefT" ret) : 

DCEInterface(sleeper_v1_(LcJispec, rel)| } 

// Member lunctions for client 
void Sleep! 
/* (in] 7 idljongjnt time 

I: 

): 

Fig. 4. < 'lieni prn\\ class declaration. The class contains several 
constructors for the Sleep function. The highlighted constructor is 
'I • used in the examples in this artit la 



HP OODCE Framework and Utility Classes 

The framework classes represent I he HP OODCE object 
model abstraction and provide the basis for DCE functional- 
ity and default behavior (see Fig. 9). Classes, such as DCE- 
Server. DCEInterfaceMgr, and DCEInterface interact with DCE 
through the DCE application programming interface. 

The idl++-generaled manager classes (server side) inherit 
from the DCEObj and DCEInterfaceMgr classes. DCEObj associates 
a C++ object instance, which may export several DCE inter- 
faces, with a specific DCE object. Each DCE object is identi- 
fied by its object OUID. DCEObj holds the CHID for the DCE 
object (see Fig. 5b). 



class sleeperj J)_ABS : public virtual DCEOb), DCEInteriaceMgrl 
public: 

// Class constructors must initialize virtual base classes 
sleeper 1_0_ABS(uuid_f obj, uuid'type): 
OCEObj(obj), 

DCEInterfaceMgrtsleeper vl 0 s ilspec, (DCEObj&)"this, type. 

(rpc_mgr_epv_l|f&sleeper vl 0 mgr))() 



© 
® 



sleepeM_OJ\BS(uuid f type) : 
DCEObj(uuidJ*)(0)|, 

DCEInterlaceMgr(sleeperji1 JLsJIspec, IDCEObj&l'this, type, 
(rpc_mgr_epv tK&sleeper vl 0 mgrlll) 

// Pure virtual member lunctions corresponding to remote procedures 
virtual void Sleepl 

I" [in] */ idl longinl time 

1 = 0; 



(a) 



class sleeper 1 0 Mgr : public sleeperj 0_ABS I 
public: 

// Class constructors pass constructor arguments to base classes 
sleeperj JLMgrluuid t'obj): 
® DCEObjlobj), 

sleeper 1 0 ABSIobj, (uuidJ'HOlK ) 

sleeper J_0_Mgr( I : 
0 DCEObjlluuid t")|0)), 

sleeper J_0 ABSIuuidJ'KOHO 

virtual void Sleepl// This is what the developer must implement 
/"(in]*/ idl long inttime 



(b) 



(?) Corresponds to (7) 
(T) Corresponds to (2) 

Fig. 5. File tooS.H server-side declarations generated by idl++.(a) 
An example of an abstract server manager declaration. (10 An 
example of a concrete server manager declaration. 
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void mainl I 

c 

try ( // Handle exceptions tram constructor or DCE calls 

T- sleeper_1_0 Mgr 1 sleeper = new sleeper l O Mgr: .7 Dynamic UUID 

- DCEPthread'exrtThd = newOCEPthread(OCEServer: ServerCleanup 01 

// MieServer->SetNamei " • ./mysleeper"); 
(?) // Register Sleeper object with server obiect 
theServer->RegisterObjecttsleepen, 

// Accept all other defaults and activate the server 
'^3J II Defaults are Use all protocols, don 1 use CDS no security 
theServer->Listent ): 

1 

// Catch any DCE related errors and print out on message if any occur 
catch IDCEErreV exclt 

traceobi < < 'Caught DCE DCEException n' < < (const char'lexec . 

) 

// Destructors are called at this point and take care ol DCE cleanup 

) 

(al 

// Developer simply implements one method to provide the implementation 

void sleeper^v. 0 Mgr::Sleep(long inttimeM 
// Call the (reentrant!) libc sleep function 
sleepttimel; 

. 

(bi 

(T) Instance of Concrete Server Class 
(?) Register Interface with the Object 
(?) Setup for Listen 

Fig. 6. (a) The server program thai ham lies requests for the Sleep 
Intel lace (li) Tin' Implementation of the Sleep function. 



Instance of a Client 
Proxy Concrete Class 



mainlint char" argvi 

{ 



fy ( 



I Handle exceptions from constructor or DCE calls 



Constructor takes a network address and protocol sequence 

sleeper t DsleepClient 1 1 unsigned char*lanjv[1 ] 

unsigned charTip'i; 

' ' The Sleep method invokes the remote procedure on the server 
sleepCliemSleeptiOI. 



catch IDCEErrS execH 
prinBTDCEException: S*\ n". (const char'lexecl. 

I 

exitioi 



Fig. 7. A client main program thai invokes th-- Sleep function on 
the server. 

DCEInterfaceMgr is an abstract base class used by the server 
side of the application to encapsulate object and type infor- 
mation as well as the entry point vector called by the BPG 
subsystem when an incoming RPC is received (see Fig. 5a). 
The manager interface is registered with the DCE run-lime 
setup and optionally with the naming service. DCEInterfaceMgr 
can retrieve the IT'lD of a particular implementation object 
instance, the entry point vector, and the pointer to the secu- 
rity reference monitor described by the DCERefMon class. 

DCEInterface is an abstract base class used by the client side 
of the application. This class controls binding and security 
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OCE Server Stub 
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RPC Protocol Engine 
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lOCERatMon. 

ACL) 



© 
Security 
Preferences 




Sets up security preferences, which have to be compatible 
with the server's security preferences 

(ij Obtains the binding handle to the server 

3 ) Ct* object instances defined in the IDL Interface 

4 C»t ontry point vectors generated by idl++ 



5 RPC run-time server endpoint and server stub 

( E ) Checks security preferences before allowing 
" the request access to the selected object 

[JJ Locates objects 

8 Set up by user 



Flit. H. The ill' i )i IDCE client/Serra an hltecture 
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• Client Proxy Ob|ecl 

• DCEInlertace 



• DCEUllld 

• DCEBinding 

• Exceptions 

• Threads 

• Name Service 
Interlace 

• DCEPassword 

• DCELoginContexl 



• Server Implementation 
Objects 

• DCEServer 

• DCEInlcrlaceMgi 
■ DCEMgmtAuth 

• OCEKeyRelriever 

• DCERalMon 



OODCECIiem 



OODCE Server 



policies and can retrieve object references. The idl++-gener- 
ated clieni proxy class inherits from the DCEInterface class 
(see Fig. 4). 

The HP OODCE utility classes add convenience to the IIP 
OODCE development env ironment. These classes encapsu- 
late DCE types and provide direct DCE functionality. For 
example, DCEUuid deals wilh lite DCE C language representa- 
tion of lite uuidj type- and ils possible conversions lo oilier 
types, while DCEBmding encapsulates DCE binding handle 
types. 

Other utility classes include: 

Security services: DCERefMon for selling security preferences 
and DCERegislry for accessing the DCE registry database 
Naming services lo model and access objects in the 
directory namespace 

Thread services to encapsulate the use of pthread mutexes,** 
c ondit ion v ariables, and I bread policies 
Error handling and tracing sen ices to support an exceplion 
mechanism and log informal ion. 

The security, naming, and I bread services are described in 
the articles on pages, 41, 28. and fi respectively. 

Additional Classes 

Additional classes can be derived from the abstract manager 
class to allow for multiple implementations for a given DCE 
interface. Each class must be registered with Ihe global 
server (DCEServer) via the theServer object (remember thai 
theServer is an instance of the DCEServer class). This allows 
the entfy point vector code to locate the object manager 
instance, verify security preferences, and allow access to 
the manager methods (see Fig. 8). If Ihe manager object is 

not Immediately located in the IIP ( xidce internal map 

managed by theServer object. Ihe entry point vector code can 
call a user-denned method to activate the manager object 
according to user-defined polices. Once activated, I lie man- 
ager object is reregistered with theServer and mapped into 
the object map. An object manager can be deactivated 
(removed from the object map) when requested by the user 
application. 

While HP OODCE adheres to the object model provided by 
DCE. two extensions have been made to enhance object 
functionality. An ObjRef class contains a reference lo an 
object and may be used to pass remote object identifies 

uuidj is a C structure containing all th£ characteristics (or a UUID 

Mutexes. or mutual exclusion locks, are used to protect critical regions ot code in DCE threads 



etg, 8. HP i it H it !E framework and 
utility class lil.run <niii|iii|ients. 

between remote objects. When an ObjRef is used to establish 
the binding lo an object. Ihe referenced object may need lo 
be activated by bringing ils persistent data inlo memory 
from a tile. HP ()( >DCE provides an activation structure that 
allows this behavior lo be implemented easily by the server. 

The application developer can add framework or utility 
classes and provide additional implementations as well as 
change some IIP OODCE default behavior. Additionally, the 
dev eloper continues to have access to the C language-based 
I )( E API. Direct use of this API is governed only by the cor- 
rect mapping of exceptions and ihe corresponding rules for 
C++ with regard to the (' language. 

HP OODCE Exception Model 

One goal of the HP ( X )DCE system was lo create a consis- 
tent error model. C++ exception handling was the natural 
choice as the basis for litis model since this mechanism is 
already well integrated into the language. C++ provides 
benefits such as object destruction and reduced source code 
size and is similar in principle to the current DCE exception 
handling mechanism. 

Despite (heir similarity, the C++ and DCE exceplion mecha- 
nisms do nol inlegrate well. Exceptions raised by one imple- 
mentation cannoi be caught by the Other, and more impor- 
tant, those generated by the DCE implementation can cause 
memory leaks if they are allowed to propagate through C++ 
code. This latter problem is a result of Ihe use of Ihe setjmp 
and longjmp functions in the DCE exceplion implementation, 
which do not allow runtime C++ to call destructors for 

temporary and explicitly declared objects before exiling a 
particular scope. 




OCEOSExccption 




Fig. io. Exception class hierarchy, 
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Throw OOOCE Exception 




Handle Exception 



Strrw Umy 
Point Vector 




Calch Exception 
Map Exception to DCE 
Status Code 
Return C-. Status Code 



Check Status Code 
Map Status Code to OCE 
Fault 



Client Pr»x| 




• Catch Exception 

• Throw 

• Map OCE Exception 
toOODCE Exception 

• Throw Exception 

• Receive Fault 

• Map Fault to OCE 
Exception 

• Raise Exception 



Transmit Fault 



Fig. 11. Exception handling in 
HP OODCE. 



To solve the problems raised by the use of two different ex- 
ception mechanisms, HP OODCE maps DCE exceptions into 
C++ exceptions. The HP OODCE classes are arranged into a 
C++ class hierarchy (see Fig. 10). DCEExcepnon is the base 
class for the hierarchy and provides pure \irtuaJ operators 
to convert exceptions to status codes or ASCII strings. The 
hierarchy contains subclasses derived from the base class 
for each of the DCE subcomponents (RPC, security, direc- 
tory services, configuration. CMA (common multithreaded 
archil eel ure) threads, and so on) so that each individual 
DCE exception can be caught by type. 

HP OODCE takes particular care lo prevent DCE exceptions 
from being propagated directly into C++ code. At the bound- 
aries between DCE C and HP OODCE C++ code, DCE ex- 
ceptions and error status codes are mapped Into HP OODCE 
exceptions and propagated into C++ code. One area (hat 
needed particular attention was in passing exceptions be- 
tween the server and client. We wanted to use the RPC run- 
time implementation of the server's communication fault 
transmission, but to do so required a "translation" layer in 
isolate RPC exceptions from IIP OODCE C++ code. This 
translation layer is implemented within I he idl + + -geueratcd 
client proxy implementation and server entry point vector 
classes (see Fig. 11). C++ exceptions raised in the 111' 
OODCE server are caught in the server entry point vector 
and mapped lo a DCE status code. This status code is then 
reiurned to the server stub, which translates the code into a 
DCE except ion and raises it lo the attention of the run-lime 
RPC. The run-time RPC lakes care of mapping the exception 
to one of the currently implemented RPC fault codes and 



then transmits the fault lo the client. Basically the reverse 
happens on the client side, except that here, the client im- 
plementation class will catch the DCE exception raised from 
the client stub and throw the HP OODCE exception back to 
the client. 
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Glossary 



Although the terminology associated with object-oriented programming and C+-* 
has become reasonably standardized, some object-oriented terms may be slightly 
different depending on the implementation Therefore, brief definitions of some of 
the terminology used in this paper ate given below For more information on these 
terms see the references in the accompanying article 

Abstract Class. Abstract classes represent the interface to mote than one imple- 
mentation of a common, usually complicated concept Because an abstract class is 
a base class to more than one derived class, it must contain at least one pure 
virtual function Obieuis ul this type can only be created through derivation in 
which the pure virtual function implementation is filled in by the derived classes 

The following is an example of an absttact base class 

class polygon I 
public. 

// constructor, destructor and other member lunctions 
// could go here .. 

virtual void rotate (>nt ll = 0;//a pure virtual function 
// other functions go here 

I; 

Other classes, such as square, triangle, and trapezoid, can be derived from poly- 
gon, and the rotate function can be filled in and defined in any of these derived 
classes 

Base Class. To reuse the member functions and member data structures of an 
existing class, C++ provides a technique called class derivation In which a new 
class can derive the functions and data representation from an old class The old 
class is referred to as a base class since it is a foundation (or base) for other 
classes, and the new class is called a derived class, f quivalent terminology refers 
to the base class as the superclass and the derived class as the subclass 

Catch Block. One (or morel catch statements follow a try block and provide ex- 
ception-handling code to be executed when one or more exceptions are thrown. 
Caught exceptions can be rethrown via another throw statement within the catch 
block. 

Class. A class is a user-defined type that specifies the type and structure of the 
information needed to create an object (or instance) of the class. 

Concrete Data Class. Concrete data classes are the representation nf new 
user-defined data types. These user-defined data types supplement the C++ 
built-in data types such as integers and characters to provide new atomic building 
blocks for a C++ program All the operations (i.e., member functions) essential for 
the support of a user-defined data type are provided in the concrete class defini- 
tion For example, types such as complex, dale, and character strings could all be 
concrete data types which (by definition) could be used as building blocks lo 
create objects in the user's application 

The following code shows portions of a concrete class called date, which is re- 
sponsible for constructing the basic data structure for the object date. 

tvpedef boolean int. 
•define TRUE 1 
'define FALSE 0 



class date I 
public: 

date lint month, int day, mt yearl, //Constructor 
-dated: //Destructor 
boolean set datelint month, mt day, int yearl: 
// Additional member functions could go here. . 

private 
int year: 

im numericaLdate, 

// Additional data members could go here.- 

}; 

Constructors. A constructor creates an object, performing initialization on both 
stack-based and free-storage allocated objects Constructors can be overloaded, 
but they cannot be virtual or static C++ constructors cannot specify a return type, 
not even void 

Derived Class. A class that is derived from one lor more) base classes. 

Destructors. A destructor effectively lurns an obiect back into raw memory A 
destructor takes no arguments, and no return type can be specified (not even void) 
However, destructors can be virtual 

Exception Handling. Exception handling in C++ provides language support for 
synchronous event handling The C++ exception handling mechanism is supported 
by the throw statement, try blocks, and catch blocks 

Member Functions. Member functions are associated with a specific object of a 
class That is. they operate on the data members of an object Member functions 
are always declared within a class declaration Member functions are sometimes 
referred to as methods. 

Object Objects are created from a particular class definition and many objects 
can be associated with a particular class The objects associated with a class are 
sometimes called instances of the class Each object is an independent object 
with us own data and state However, an object has the same data structure (but 
each object has its own copy of the data) and shares the same membet functions 
as all other objects of the same class and exhibits similar behavior For example, 
all the objects of a class that draws circles will draw circles when requested to do 
so, but because of differences in the data in each object's data structures, the 
circles may be drawn in different sizes, colors, and locations depending on the 
stale of the data members for that particular object 

Throw Statement. A throw statement is part of the C++ exception handling mech- 
anism A throw statement transfers control from the point of the program anomaly 
to an exception handler The exception handler catches the exception A throw 
statement lakes place from within a try block, or from a function in the try block 

Try Block. A try block defines a section of code in which an exception may be 
thrown A try block is always followed by one or more catch statements 
Exceptions may also be thrown by functions called within the try block 

Virtual Functions. A virtual function enables ihe programmer to declare member 
funciions in a base class lhat can be redefined by each derived class. Virtual 
functions provide dynamic (i.e.. run-lime) binding depending on the type of obiect 
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HP Encina/9000: Middleware for 
Constructing Transaction Processing 
Applications 

A transaction processing monitor for distributed transaction processing 
applications maintains the ACID (atomicity, consistency, isolation, and 
durability) properties of the transactions and provides recovery facilities 
for aborting transactions and recovering from system or network failures. 

by Pankaj Gupta 



Transaction processing systems are widely used by enter- 
prises to support niission-criiica] applications, such as air- 
line reservation systems and hanking applications. These 
applications need tO store anil update data reliably, provide 
concurrent access to the data by hundreds or thousands of 
users, and maintain the reliability of the data in the presence 
of failures. 

The HP Eneina/9000 transaction processing monitor 1 pro- 
vides the middleware for running transaction processing ap- 
plications. It maintains ACID (atomicity, consistency, isola- 
tion, and durability) properties for transactions I sec the 
glossary on page 05). It ensures that applications thai run 
concurrently will maintain data consistency. Encin;i/!I0()0 
also provides recovery facilities for aborting transactions 
and recovering from failures such as machine or network 
crashes. 

DCE and Distribution 

Encina/9000 prov ides the ability to write distributed applica- 
tions. Eneina/9000 applications can be written as client/server 
applications with the client and server possibly running on 
different machines. Encina/9000 servers can communicate 
and cooperate with eac h other in updating data on several 
different machines. 

Distributed applications provide several advantages. The 
data maintained by an enterprise may itself be distributed 
because of historical and geographical considerations. 
Furthermore, distributed applications are able to exploit 
parallelism by running concurrently on several machines. 

Distributed computing offers the advantage or improved 
performance, availability, and access to distributed data. 
Performance is improved by spreading the computing 
among various machines. For example, the application's 
use? interface can be run on a PC while the user code could 
be split to run on several machines. The use of multiprocess- 
ing machines to provide parallelism for multiple Users can 
improve the throughput of the system. Availability can be 
increased by a distributed system in which replication is 
used to keep several copies of the data. Access to distrib- 
uted data or lo data that is maintained in several databases 
is also lac ilitaled by distributed computing. 



Data may be distributed because the database becomes too 
large or the CPC on the database machine becomes a bottle- 
neck. Data can also be distributed to increase availability 
and improve the response time by keeping the data close to 
the users accessing it. Finally, data can be distributed to 
keep separate administrative domains, such as different 
divisions in a corporation that want to keep their data local. 

Enc ina/9000 uses the Open Software Foundation's DCE - 
(Distributed Computing Environment ) as the underlying 
mechanism for providing distribution. It uses the DCE UPC 
mechanism to provide client/server communication. Encina/ 
9000 is also very closely tied to DCE naming and security 
services (see the articles on pages 28 and -II for more about 
these seivices), For example, an Encina/9000 server can be 
protected from unauthorized use by defining access control 
lists ( ACLs), ACLs contain an encoding of the authorization 
policy for different users and are enforced by DCE at run 
time. ACLs are described on page lit. Encina/9000 also 
makes use of the threading package provided by DCE. 

To achieve optimum price and performance, careful consid- 
eration needs to be given to how the data and the applica- 
tion arc partitioned. Throughput and response limes are 
often the key criteria by which users judge the performance 
of a system. Encina/9000 provides the flexibility of being 
able to specify the distribution topology of the applic ation. 
In addition, users can specify data replication if it will help 
to ensure higher availability of mission-critical data 

Two-Tiered versus Three-Hered Architectures 

In the past, transaction processing applications were imple- 
mented using a two-tiered architecture (see Fig. I ). In this 
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paradigm an application is written as a client, which accesses 
a ilalaliasc servei The cliciil implements Ihe graphical user 

interface mi I) and ihe application logic The database 
server handles access to the data stored in a database. 

The advantage of this approach is simplicity. The disadvan- 
tage is lhal il is nol scalable beyond a certain point, h is also 
less flexible and harder to modify to meet new business 

needs. 

Encina/9000 allows the development of applications using a 
three-tiered architecture like Ihe one shown in Fig. 2. In this 
paradigm, an application is partitioned into a client that im- 
plements ihe graphical user interface to the user, an applica- 
tion server that implements the business logic of the appli- 
cation, and a database server thai implements Ihe database 
access. 

The Enema/9000 three-tiered architecture provides the fol- 
lowing advantages over traditional two-tiered architectures: 
Decoupling the <ILT from the business logic 
Scalability of the architecture to support a very large num- 
ber of users and a high transaction throughput 
Accessibility lo multiple database servers from an applica- 
tion server 

Freedom from being tied into any particular database 
vendor 

Tight integration with the distributed computing facilities 
offered by DCE 

Choice of transactional applications lhal support any com- 
bination of RFC, CPI-C t Common Programming Inierface 
for Communications), and queued message communication 
Ability to retain data on a mainframe or other legacy com- 
puter and reengineer by adding HP- 1 'X* application servers, 
providing lower cost and higher price/performance relative 
to some mainframe systems. 

Three-tiered architectures are more complicated in general 
but provide greater flexibility of application design and de- 
velopment. Among the reasons why users are willing lo give 
up the simplicity of the two-tiered architecture is the faster 
response times and the more effective user interfaces pro- 
vided by the three-tiered architecture. The ability to provide 
a front-end workstation that supports graphical user inter- 
faces gives an application a more effective user interface. 
For applications that require access to data distributed across 
large geographic regions, a Ihree-liered architecture offers 
more flexibility to lime the communications to compensate 
for WAN delays and improve availability. This results in a 
faster response time because Ihe user is accessing local data 
most of the time. Propagation of the data to other machines 
can be queued and performed offline. Therefore, geographi- 
cally distributed data can be maintained without having to 
perform expensive distributed two-phase commit protocols 
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online. Two-phase commits lhal happen over wide area net- 
works are expensive and care must be taken when designing 
distributed applications to minimize the amount of two- 
phase commits over the network. Queued communications 
also improve availability. See page <>"> for a definition of 

commit. 

Components of Encina/9000 

Fig. 3 shows the architecture for Ihe implementation of 
Encina/9000 dial runs on the HP-l X* operating system. 

Each of the components shown in Fig. 3 is packaged inde- 
pendently. A machine lhal runs Encina/9000 clients only can 
be configured without Ihe Encina/9000 server software. 
Machines lhal run Encina/9000 servers must be configured 
with both the Encina/9000 client and server components. 

Encina/9000 applications that can be configured CO tun on 
top of the Encina/9000 server component include 

• Peer-to-peer communication, which provides transactional 
access to data stored on mainframes and workstations run- 
ning the HP-l "X operating system 

• Structured file system, which is a record-oriented file sys- 
tem base on the X/Open -' ISAM (index sequential access 
method ) standard 

• Recoverable queueing service, which provides applications 
with the ability to enqueue and dequeue data 

• Monitor, which is an infrastructure for application develop 
ment, run-time support., and administration. 

The DCE components used by Encina/9000 include: RFC, the 
directory' service, the security service, and threads. 

Encina/9000 Toolkit 

The Encina/9000 client component is also called the Enema/ 
9000 toolkit executive and the Encina/9000 server component 
is also called the Encina/9000 toolkit server core. Together 
these components are called the Encina/9000 toolkit. 

Fig. 4 shows Ihe components that make up and support the 
Encina/9000 toolkit. 

Base Development Environment. The lowest layer of the 
Encina/9000 toolkit is the base development environment 
It provides developers of other Encina/9000 components 
with a uniform set of features independent of the underlying 
operating system. The base development environment library 
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Fig. 3. The architecture of Encina/9000 on Ihe HP-l : .\ operating 
system. 
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provides a common platform independent threading inter- 
face and an abstraction for low-level functions so tltat the 
upper layers that use the base development environment 
can be independent of differences in the operating system or 
the hardware platform on which Encina/9000 runs. 

The base development environment provides SupfMIt for 
multiple threads of execution by using DCE threads. Also, it 
provides thread-safe routines for the following functionality: 
Memory management 
File I/O 

Process management 
Signal handling 
Timers and alarms 
Native language support. 

The base development environment is intended primarily for 
I he development of other Eneina/9000 components. 

Transaction Manager. The transaction manager provides the 
ability to demarcate transactions, which means that it Ls 
able to specify the beginning, the commit, and the abort of a 
transaction. Internally it supports a dislributed two-phase 
commit management protocol, including the ability lo per- 
form coordinator migration. 

The transact ion manager supports nested transactions capa- 
bility/' which allows nested transactions to be defined within 
a top-level transaction. Nested transactions have isolation 
and durability properties similar to regular transact ions, bul 
the abort of a nested transaction does not cause the top-level 
transaction to abort. This allows a finer granularity of failure 
isolation in which the main transaction can handle the fail- 
ure of certain components implemented with a nested trans- 
action. Nested transactions are defined in the glossary on 
page ii">. 

The application must be carefully designed since failures 
such as crashed server nodes, which cause a nested trans- 
action lo fail, could in some cases also cause the lop-level 
transaction to fail. The Eiieina/9000 structured file system 
provides support for nested transactions for data stored in 
structured files. However, database vendors like ( hade do 
not currently support nested transactions in their products, 
making it impossible to exploit the advantages of Enctna/ 
9000's nested transaction capabilities for data stored by 
these relational databases. 
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The Encina^.KX) transaction manager provides an applica- 
tion program with the ability to issue callbacks on events 
related to the transaction's commit protocol. This enables 
the programmer to write routines that are invoked before 
the transaction prepares or aborts or after the coordinator 
decides to abort or commit the transaction. 

The transaction manager allows transactions to be heuristi- 
cally committed by a system administrator. This should only 
be used in rare cases in which the transaction coordinator is 
unavailable and the administrator does not want to block 
access to locked data and lias to trade off data availability to 
avoid possible data inconsistency. 

Thread-to-TID. Since Eneina/9000 makes use of DCE threads, 
the work done on behalf of a user transaction can be com- 
posed of several different threads. The thread-tn-TID service 
associates a transaction with a thread and maintains the 
mapping between a thread and a transaction identifier (Til) ). 
This service is used by other Encina/9000 components and is 
rarely used by programmers directly. 

Transactional RPC. The Encina/9000 transactional RPC ser- 
vice enhances the DCE RPC mechanism to provide transac- 
tional semantics for remote procedure calls. Unlike remote 
procedure calls, transactional RPCs have once-only seman- 
tics, [f a transaction performing an RPC commits, then the 
RPC is guaranteed to have executed once and once only. If 
the transaction performing an RPC aborts then the RPC is 
guaranteed not to have executed (if the RPC was executed 
its effects are undone by the transaction abort). 

A transaction can make transactional RPC calls to multiple 
servers, and a server can in turn make a transactional RP< ' 
call to another server. 

The transactional RPC service extends the DCE RPC model, 
'flie interface definition for the service executed on behalf 
of a transaction is defined in a TTDI. (Transactional Interface 
Definition Language) file, which is similar to a DCE IDI. 
file.* This file nitisi be prepn icessed with a TID1. compiler 
(similar to an IDL compiler). The TTDI. preprocessor gener- 
ates client stubs, server stubs, a header file, and an IDL file. 
The DCE IDL preprocessor is run on the IDL file to generate 
additional stubs and header files. The client and the server 
execuiables are generated by compiling and linking the vari- 
ous stub sources and libraries. This process is illustrated IB 
Fig. 5. 

Transactional RPC also supports nontransnctional RPCs (a 
nonlnuisactional RPC call can be made by calling the trans- 
actional RPC service). The TIDL file for the service interface 
must specify that the service is iiontransactional. 

Log. This component of Encina/9000 provides logging capa- 
bilities. It provides write-ahead logging (see glossary) for 
storing log records that correspond to updates to recoverable 
data and log records that o irrespi uiti lo transaction nut- 
comes. The log records are used by the transaction manager 
to undo the effects of transact ions that have aborted and lo 
ensure that the committed transactions are durable. 

' See Ihe article on page 55 for mare about IDI tiles 



Fig. 4. \ detailed view of the componenta that make up and support 

the Enriiui/tllMK) toolkit 
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(T) Preprocess transaction through the TIDL compiler 
(?) Run the I0L file created in (T) through the IDL compiler 

3 Create the client program. 
1 t) Create the server program. 

For earlier versions of Encina/9000, the log service was 
implemented to provide a log serv er (hat could he used by 
many different clients to siore log records. The latest ver- 
sion of Encina/9000 supports (he log serv ice as a library 
which is linked into the client code. 

The log service supports archiv ing of log data for crash and 
media recovery, ll also supports mirroring of data. 

Lock. This component provides two-phase locking (see glos- 
sary) faciliiies lo ensure (he isolation and consistency prop- 
erties of transactions. Applications can request locks on 
resources before accessing them, and the lock manager 
ensures dial the lock requesl on behalf of a transaction will 
not be grained if another transaction holds a conflicting lock 
on thai resource. Locks are released automatically when Ihe 
transaction completes, and the application may also request 
early release of locks when il is safe lo do so. The lock ser- 
vice also supports locking for nested transactions. 

The locking service implements logical locking in which the 
programmer defines lock names and associates the lock 
names with physical resources. When a programmer wants 
to lock a physical resource, die logical lock name associated 
with that resource is specified in the call to the locking 
service 

In addition to supporting the conventional read/write locks. 
Encina/S'OOO also supports intention locks and instant dura- 
tion locks. Intention locks are used to declare an intent to 
subsequently lock a resource. The use of intention locks can 
reduce the potential for deadlock among concurrent trans- 
actions. Instant duration locks are locks that are grained but 



Fig. 5. The steps Involved In turning 
a transaction intoettent Mid server 

i-X''eilt;ili|es 

not held and can be used to implement complex locking 
algorithms. 

The lock service also provides the ability lo deiennine if a 
transaction is deadlocked or not. 

Volume. This component maintains the data storage in terms 
of logical data volumes. I( provides Ihe ability to manage 
very large files and view multiple physical disks as a virtual 
file. It also supports (he ability lo minora data volume 
transparently to Ihe client. The volume component some- 
limes sacrifices speed for increased reliability and may be 
inappropriate for certain applications. This component is 
currently not used by Ihe log component. 

TM-XA. The Encina/!»0(in T.M-XA component implements the 
X/Open XA interface. The XA interface is a bidirectional 
interface between a transaction manager and a resource 
manager such as a dal abase. The XA interface provides a 
standard way for I ransact ion managers to connect to data- 
bases. 

The use of TM-XA with die Encina/SlOOO monitor is recom- 
mended. In Ibis case (he server registers each resource man- 
ager with a call providing the name of the resource manager 
and an associated switch slructure. 4 which gives the Encina/ 
90(H) TM-XA component information about the resource 
manager. In addition, the server must also be declared as a 
recoverable serv er. TM-XA allows Encina/9000 to book up 
with Standard database products such as Oracle, Informix, 
and so on. 
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Glossary 

The following are txief definitions of some of the transaction-related termmology 
Ond in the accompanying article 

Transactions and ACID 

A transaction rs the logical grouping of a user function performed as a unit so mat 
it maintains its ACID (atomicity, consistency, isolation, and durability) properties 
Transactions allow users to execute their programs and modify shared resources 
like databases fa the presence of simultaneous access and updates by multiple 
users and in the presence of various kinds of failures 

Atomicity of a transaction means that either all the actions specified within the 
transaction will be performed or none of them will be performed This ensures that 
a transaction is not partially applied, which is desirable since a partial application 
of the user transaction could leave the database in an inconsistent state Consis- 
tency means that the database consistency is preserved in the presence of concur- 
rency among multiple users Isolation means that while the transaction is execut- 
ing, its effects will not be visible to other concurrently running transactions. Dura- 
bility means that once a transaction has been successfully completed the effects 
of that transaction are made permanent and survive failures. 

Commit, Abort, and Prepare 

A successful completion of a transaction is called a commit of the transaction. 
Before a transaction commits, it can be aborted either by the user or by the trans- 
action processing system. 

A user organizes a set oi actions in a transaction with the intent that all of these 
actions should happen or none of these actions should happen. An example of 
such a transaction is a transfer of money between a person's savings account and 
checking account This transaction consists of the actions of changing the savings 
account balance and the checking account balance. If the transaction is successful 
then both these account balances should be changed, one debited by amount X, 
and the other credited by amount X Any other outcome would be in error. When 
the user submits this transaction and all operations in the transaction are success- 
fully carried out. the transaction is said to have committed. 

II may not always be possible to commit a transaction for example, the machine 
thai maintains the checking account balance may be down, or the user may have 
supplied an incorrect personal identification number (PINI or decided to cancel the 
request after submitting it. If the transaction cannot be performed, then it is said 
to have been aborted or simply to have aborted. If a transaction is aborted 
(aborts!, then none of the actions of the transaction are performed (or if they had 
been performed they are undone! 

Transaction processing systems use mechanisms like two-phase locking to ensure 
the isolation properties, and two-phase commit protocols to ensure that all the 
participants within a transaction can be atomically committed or aborted ' 



A Two-phase commit protocol is typically used to commit a transaction in which 
multiple participants are performing actions requestea by the transaction One of 
these participants is called the coordinator In the first phase of the two-phase 
commit protocol, the coordinator sends a prepare message to all the participants, 
asking them to prepare the transaction ana send a message back indicating 
whether or not thev can prepare the transaction If all the participants respond 
that thev can prepare the transaction, the coordinator writes a record in its log 
indicating that the tfarBaction is commmed and instructs all the participants to 
commit the transaction (this is the second phase of the protocol! If any participant 
responds back to the coordinator that it >s unable to prepare the transaction, the 
coordinator notes m its log that the transaction is aborted and instructs all parte- 
pants to abort the transaction 

When a participant receives a commit message from the coordinator in the second 
phase, it must ensure that all the actions of the transaction are durably stored on 
disk When a participant receives an abort message horn the coordinator m the 
second phase, it must ensure that all the actions of the transaction are undone. 
Therefore, m the first phase of the two-phase commit protocol, the participant 
must ensure that data is stored reliably in logs that enable it subsequently to undo 
the effects of a transaction or make permanent the effects of a transaction 

Nested Transaction 

In the nested transaction model, a transaction (also called a top-level transaction! 
can be decomposed into a tree-like hierarchy For example, a debit-credit transac- 
tion can be decomposed into two subtransactions, one for debit and one for credit 
The debit or credit subtransactions could be further decomposed into smaller 
subtransactions. A subtransaction maintains the durability and consistency proper- 
ties of its parents. The difference is that a subtransaction can be aborted and 
teexecuted without aborting its parent In the debit-credit example, the debit 
subtransaction can be aborted and reexecuted without having to abort the entire 
transaction. In this case the top-level transaction verifies that each subtransaction 
can be committed at the time of transaction commit 

Two-Phase Locking 

Two-phase locking means that a transaction will have two phases In the first 
phase the transaction can only acquire and not release locks, and in the second 
phase it can only release and not acquire locks. 

Write-Ahead Logging 

For data recovery, transaction processing systems use a log to log data that is 
being modified. In write-ahead logging, data is copied to the lug before it is over- 
written This ensures that if the transaction is aborted, the data can be restored to 
its original state. 

Reference 

I J Gray and A Reuteis, Transaction Processing Concepts and Techniques. Muigan Kaulman. 
1993 



TM-XA allows an Encina/iHIOO application to make calls to 
one or more resource managers that support the XA inter- 
face. The Encina/!«)00 application starts a transaction, 
accesses a resource manager using its native SQL interface, 
and then commits the transaction. The TM-XA software 
coordinates the commit of the transaction among the vari- 
ous resource managers and other Encina/ SMHMI components 
(like the structured file system or the recoverable queuing 
System} which might be accessed by the user Iransaction. 

Recovery. This component drives the recovery protocols to 
recover from failures. If provides recoverable memory man- 
agement. Recovery also provides the ability to perform: 
Aboti recovery. This ensures that after a iransaction is 
aborted! il is rolled back at all participating siles. 
Crash recovery. This provides a recovery after a syslem 
failure by rolling back all the transactions that had not been 



commiltcd and rolling forward all the commilled trans- 
actions. 

• Media recovery. This is used to provide recovery when data 
written to the disk is destroyed. 

The recovery component produces and uses the records 
written by the log serv ice and ensures the consistency of 
transactional data. In the ease of a transaction failure, the 
recovery component undoes the effects of a transaction. 
During recovery from a system failure, flu's component will 
examine the records in the log, appropriately commit or 
aboil transactions for which il finds records in the log, and 
bring I he data to a consistent state. 

For media failures, lite syslem administrator must provide 
archives dial are used by the recovery component to restore 
Ihe data to the stale it was in when the archive was created. 
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There may lie a loss of data in the case of media recovery. 
Encina/9000 also prov ides the ability to perform online back- 
ups to create the media arc-hives necessary for recovery- 



be executed as a subiransaction within the parent trans- 
action. The subThread construct allows a created thread to be 
executed as a separate thread within a nested transaction. 



Tran-C 

Encina/9000 provides extensions to the C programming lan- 
guage to make it easy to invoke the functionality provided 
by the Encina/9000 toolkit. Tran-C consists of library func- 
tions and macros that provide a simple programming para- 
digm so that the user does not have to access the toolkit 
module interfaces directly. The user can invoke high-level 
Tran-C constructs rather than the lower-level toolkit calls. 
The use of Tran-C versus toolkit calls is analogous to using a 
high-level language versus assembly language. Using the 
toolkit primitives directly is much more flexible, but the 
flexibility comes at the price of far greater complexity. 
In general. Tran-C is recommended for application 
programming. 

Hie most important constructs provided by Tran-C are the 
transaction. onComrnit. and onAbort clauses. These constructs 
provide a mechanism for the programmer to start a trans- 
action and declare code to execute when the transaction 
commits or aborts. This is illustrated in Fig. li. The applica- 
tion programmer is freed from the task of initializing all the 
underlying toolkit components and manually managing 
transaction identifiers, transactional locks, and other trans- 
actional metadata. All the code bracketed by the transaction 
clause is executed on behalf of the same transaction. When 
a transaction bounded by the transaction construct aborts 
(or commits), control in the program automatically transfers 
to the associated onAbort (or onComrnit) clause. 

Tran-C also supports nested transact ions and multiple threads 
of control. The concurrent and color constructs can be used to 
create multiple concurrent threads within a transaction. The 
concurrent construct is used to enable an application to con- 
currently execute a predetermined number of threads, while 
the color construct enables the application to concurrently 
execute a variable number of threads. Borh constructs pro- 
vide the ability to create multiple threads which can be run 
either as subtransactions or as concurrent threads within the 
transaction. The subTran construct allows a created thread to 
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Toolkit Example 

Fig. 7 shows an example of the interactions between the 
components of the Encina/9000 toolkit. In this example a 
client makes a call to update data stored by a database and 
then commits the transaction. The following steps are asso- 
ciated with the circled numbers in Fig. 7. 

1. The client starts a transaction by making a c all to the 
transaction manager. 

2. The client performs a transactional RPC by making a call 
to the transactional RPC component. 

3. The transactional RPC component makes a call to the 
transaction manager to obtain transactional data for the 
transaction. 

4. The transactional RPC component calls DCE RPC to 
transmit the user data and transactional data to the server. 

5. DCE RPC (on the server) makes a call to the transactional 
RPC. 

(i. The transactional RPC component passes the transactional 
information to the transaction manager. 

7. The transaction manager uses the TM-XA interface to call 
the resource manager. 

8. The transactional RPC component calls the user function 
that makes SQL calls to the resource manager. The resource 
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Fig. 6. \ code fragment illustrating the use of the Tran-C constructs 

Transaction. onComrnit, and onAbort. 



Fig. 7. An example of the interactions bet ween components of 
the Encina/fM 100 toolkit. 
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manager performs the appropriate locking and updating of 
its data. 

9. The user function on the server returns to that trans- 
actional RPC component which then returns to the client via 

DCE. 

10. The client calls the transaction ntanager to commit the 
transaction 

11. The transaction manager uses a two-phase commit pro- 
tocol to commit the transaction. It contacts all the trans- 
action manager participants that have participated in the 
transaction. Each transaction manager uses the recovery 
and log components to log the prepare and commit deci- 
sions during various phases of the commit protocol for the 
transaction. 
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Fig. 8. ft PPC configuration showing the PPC gateway tninsblmg 
TCP/IP protocol to SNA protocol. 



Peer-to-Peer Communications 

Encina/9000 peer-to-peer communicat ions, or PPC. provides 
transact ional access to data stored on mainframes, and it 
performs a distributed two-phase commit of data stored on 
mainframes and HP 9000 servers. This allows mainframe 
applications to participate in an Encina/9000 transactional 
application, and conversely, an Encina/9000 application is 
able to participate in a mainframe Iransactional application. 
Encina/9000 PPC uses a two-phase commit sync prolocol 
(sync level 2) lo commit a transaction that accesses data on 
a mainframe and an HI' 9000 server. 

PPC services are implemented as a PPC executive and a 
PPC gateway product. These products can be purchased 
separately. The PPC executive is a library that runs in a DCE 
cell, and the PPC gateway is a server that acts as a gateway 
between DCE and SNA communications protocol. This gate- 
way allows Encina/9000 applications to communicate with 
LU (S.2 applications." 

A typical PPC configuration involves an Kncina/9000 I'I'I ' 
application running in a DCE cell and communicating with a 
PPC gateway server running in the same DCE cell. The PPC 
gatewnj server communicates « ith the mainframe using an 
SNA communications package. PP< ' provides the ahililv lo 
write Encina/9000 applications that act as either the coordi- 
nator or the subordinate in a transaction between an Encina/ 
9000 system and a mainframe host. Encina/9000 application 
programmers use the CPI-C API Tor coding the PPC compo- 
nent. The PI'( ' gateway translates the CPI-C conversations 
from TCP/IP to UJ6.2. This is illustrated in Fig. 8. 

Structured File System 

The structured file system is a record-oriented file system 
based on the X/Open ISAM standard. It provides an alterna- 
tive to other commercial resource managers and the ability 
lo support nested transactions that access data in the struc- 
tured file system. It also provides full transactional integrity. 

The records in the structured file system contain different 
fields that can be indexed by primary keys and secondary' 
keys. The structured file system's field and record types are 
similar to those used by the recoverable queuing service 
(described below), allowing applications to have easy access 

' LU 6 2 applications are mainframe applications that are wntlen lo run on lop ol IBM's IU 6 7. 
protocol 



lo both systems. In addition, the Structured file system sup- 
ports a COBOL interface with the structured file system's 
external file handler. 

Files in the structured file system are organized in one of the 
following three ways: entry-sequeneed, relative, and B-tree 
clustered (see Fig. 9). Records in an entry-sequenced file are 
stored in the order in which they are written into the file. 
New records are always appended to the end of the file. A 
relative file is an array of fixed-length slots. Records can lie 
inserted in the first free slot found from the beginning of the 
file, at the end of the file, or in a specified slot in the file. A 
B-tree clustered file is a tree-structured file in which records 
with adjacent index names are clustered together. 
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• As records are inserted in time they 
are appended to the end 

• Deleted records leave a blank space. 



Relative File Structure 
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Records are organized as a B tree The 
record key is used to traverse the tree to 
locate the appropriate record. 



Fig. 9. Kile organizations supported in i Im' structured, file system. 
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The structured file system is simple and fasl, but limited in 
flexibility when compared to relational databases. Relational 
databases provide powerful and complex access semantics 
with operations such as select,, join, aggregate, and so on. 
The Structured file system provides low-level access to rec- 
ords whose formats are user-defined and controlled. 

Recoverable Queueing Service 

Enema/9000 provides a recoverable queueing service which 
is layered on top of the basic toolkit and server core compo- 
nents. This service provides applications with the ability to 
transactionally queue and dequeue data. Application devel- 
opers can write applications that transactionally update data 
in a resource manager like a database and queue or dequeue 
data with the guarantee that either both operations will 
succeed or both operations will aboil. 

An example of a transactionally recoverable queue would be 
a banking application thai sends a letter to a customer if the 
customer's balance goes below zero. The action to generate 
the letter can be queued and processed later at the end of 
the day. The recoverable queue ensures that this action will 
always be performed even in the event of system failures. 

One advantage of the queueing model is that applications 
can offload some work to be done at a later time. This de- 
ferred mode of computing is in contrast with the RFC style 
pf communication in which an application invokes a service 
to do the processing as soon as it can. 

A queue is a linear tlata structure. Elements in the data 
structure are queued in a particular configurable order and 
the dequeue occurs on a FIFO (first in, first put) basis. An 
element of a recoverable queueing service queue is Struc- 
tured in a record-oriented formal. Eneina/9000 supports 
queues that may contain elements of different data types. An 
element key is a sequence of one or more fields of an ele- 
ment type that are used to retrieve an element. 

Encina/9000 provides the ability to define one or more re- 
coverable queueing service servers in an Encina/9000 cell. 
Each server can internally support multiple queue sets. A 
queue set is a collection of queues within a recoverable 
queueing service server. Applications can queue or dequeue 
to or from a particular queue set. Queues within a queue set 
can be assigned priority classes relative to each other. Also, 
service levels define how to distribute the dequeues so that 
the queues with lower priority are not starved. 

The recoverable queueing service supports a weak FIFO 
locking behavior. For example, when two transactions con- 
currently dequeue from a queue, each obtains a lock on the 
first element that it can lock on the queue. It is possible for 
the transaction thai obtained a lock on the second element 
in the queue to commit before the transaction that obtained 
a lock on die first element in die queue. Another consequence 
of the weak FIF< > locking policy may be that a transaction 
thai consecutively queues multiple elements may not be 
able to place all these elements in that queue hi an uninter- 
rupted sequence. 

The recoverable queueing service uses the DCE security 
mechanisms to secure access to the queue. Administratively. 



ACLs (access control lists) can be set up to authorize users 
or groups to be able to perform queue operations like read 
from queue, queue to the queue, dequeue from the queue, 
delete a queue, and so on. 

A recoverable queueing service queue can be scanned using 
element keys, cursors (for sequential access), or element 
identifiers. 

Finally, the recoverable queueing service provides the ability 
to register callbacks with the service's server on callback 
quantities such as the number of elements, size in bytes, and 
work accumulation. For example, with this feature it is pos- 
sible to write applications thai can ask the recoverable 
queueing Service Server to inform them when ten elements 
have been queued. 

Monitor 

The Encina/9000 transaction processing monitor provides 
an infrastructure for application development, run-time sup- 
port, and administration. It supports the development of a 
three-tiered architecture in which multiple clients can access 
data stored in multiple resource managers. 

Like DCE, the Encina/9000 monitor also has the concept of a 
cell. For the Encina/9000 monitor the cell is called an Encina 
cell. The Encina cell is a subset of the DCE cell, and multiple 
Encina cells can be defined within a DCE cell. (DCE cells 
are described in the article on page 0.) An Encina cell may 
consist of multiple nodes. A node is eit her a public node or a 
Secure node. A secure node is a node on which the Encina/ 
9000 servers can be securely run. Public nodes are nodes 
Where only clients are run. Servers are not configured to run 
on public nodes. An example of an Encina cell is shown in 
Fig. 10. Like DCE, an Encina cell has a cell administrator 
who is responsible for performing administrative tasks. 



Public Node 




Secure Node 



Application 
Server 



Cell 
Manager 



Node 
Manager 



I 



Secure Node 



Node 
Manager 



Slruclured 
File System 
Server 



I 



Secure Node 



Recoverable 
Queueing 
Service 
Server 



Node 
Manager 



Application 
Server 



Fig. 10. The components In an Encina/9000 cell. 
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The encina cell contains the following server processes: 
Cell Manager There is one cell manager process in an 
Eni ina cell. The cell manager maintains the data needed 10 
configure and administer the Encina cell. This data is stored 
in a data repository' managed by the structured file system. 
The data describes how the application servers are config- 
ured to run on the secure nodes and includes the authoriza- 
tion information for those servers. The cell manager also 
monitors the state of the node managers and keeps statistics 
on the use of Ihe servers by the clients. 
Node Manager. There is one node manager process in each 
secure node in ait Encina cell. The node manager monitors 
the application servers that are running in that node. If an 
application server fails, the failure is detected by the node 
manager which then restarts the application server. 
Application Server. The server part of a user application is an 
applic ation Server. Typically, application servers accept calls 
from an Encina cell's clients and then process the user re- 
quests by ac cessing one or more resource managers. Appli- 
cation serv ers may be recoverable or ephemeral. A recover- 
able application server is one that uses the underlying 
Encina/9000 facilities to provide the ACID ( atomicity, con- 
sistency, isolation, and durability) transactional properties. 
When a recoverable server fails, it performs recovery on 
restart which guarantees the consistency of the data. An 
ephemeral server does not provide the ACID properties to 
the data it accesses. An application server consists of a 
scheduling daemon process ( called mond) and one or more 
processes (caller! PAs) that accept client requests. PAs are 
multithreaded processes. The mond coordinates the clients' 
requests for servers and assigns a PA to a requesting client. 
In this respect the role of the mond is similar to that of the 
RPC daemon rped in DCE. The mond also monitors the PAs 
and automatically restarts a PA in the event that the PA dies. 
An example of an application running in an Encina/9000 cell 
is shown in Fig. 1 1. 

In the Encina/9000 monitor environment, a client can make 
a server request using explicit binding or transparent bind- 
ing. With transparent binding Ihe client simply makes a call 
to the server and the monitor environment is responsible for 
routing the client request to an appropriate server. Willi ex- 
plicit binding, a client explicitly binds to a particular server. 
The Encina/9000 monitor provides a call to request a list of 
all servers exporting a particular interface, a call to get a 
handle to a mond for one of those servers, and a call to gel a 
handle to a PA that is under Ihe eOfltTO) of a particular mond. 
When using explicit binding, a client can specify that Ihe 
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client block if the PA is busy or that it get back a status if the 
PA is busy. In addition, the client can request that the PA be 
reserved for that client by specifying a long-term reservation 
to the server. 

In general it is easier to code the client to use transparent 
binding. This also has the advantage that the monitor code 
can perform load balancing of c lient requests among the 
available PAs. The monitor software uses a probabilistic 
algorithm to route client requests to the available PAs in a 
ratio predefined by a system atiiTiinistrator. With transparent 
binding the monitor software will use an existing binding if 
one exists, or it will create a binding to an appropriate 
server if no such binding exists. If all the available servers 
are busy, the client waits at the server for a free PA. 

Although it is more complicated to write clients that use 
explicit binding, it does provide the user with the ability to 
select the PA on which the call is executed. There are cer- 
tain situations in which explicit binding used in conjunction 
with long-term reservation of PAs is advantageous. For ex- 
ample, consider a client process servicing a large number of 
users. In this case it would be advantageous for that process 
to reserve a PA and then direct the various user requests to 
that PA. Having a direct connection to a PA reduces the time 
needed to connect to a PA on subsequent calls. Long-term 
reservation makes the PA unavailable to other clients, and it 
must be used with care. Actaiinistratively, a timeout interval 
can be specified so that if there are no client calls to the PA 
within that interval, the long-term reservation is c anceled. 
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When an application server is initialized, it can specify one 
of the three scheduling policies: exclusive', concurrent shared, 
and shared. Shared scheduling is provided primarily for 
compatibility with previous releases, and its use is not 
recommended. The default policy is exclusive scheduling. 
With this scheduling only one client RPC can be executing 
within a given PA at any tote, and the PA is scheduled exclu- 
sively for the entire duration of the client transaction. This 
has ihe advantage I hat Ihe programmer does not have to be 
concerned about issues related to threading, This is required 
when Ihe PA is accessing a database that is not thread safe 
(which is currently the case for most RDBMSs). 

Willi concurrent shared scheduling, many clients can be 
executing within a PA at the same time, and the multi- 
threaded PA assigns a different tliread Tor each client re- 
quest. If the PA accesses global or sialic- variables, they must 
be protected by DCE synchronization facilit ies such as 
nnitexes.* Concurrent shared scheduling should only be 
used when linking with thread-safe libraries. Concurrent 
shared scheduling provides Ihe best performance with the 
lowest use of resources. 

The monitor allows the creation and access of monitor- 
shared memory (IIP 9000 virtual memory) which can be 
shared among the PAs within an application server. This 
allows a quick and easy way for the PAs to share transac- 
tional data. Monitor-shared memory is much cheaper than, 
say. using an external RDBMS, but care should be exercised 
when using the monitor-shared memory because il is Ihe 
user's responsibility to perform the appropriate locking 
when accessing the shared memory. Since locks must be 

' Mutexes. 01 mutual exclusion locks, ate used 10 protect critical regions of code in DCE threads 
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used, it also has 1 1 it- potential of introducing deadlocks. 
Transactional timeouts can be declared for aborting such 
transactions. 

The monitor allows the use of the recoverable queueing ser- 
vice for queueing work items which are eventually processed 
by a monitor application server. Using the queued request 
facility, entries of the appropriate type are queued to the 
recoverable queueing service. A queued request facility 
daemon will then dequeue the request and forward the 
request to the appropriate PA. 

The Encma/yooo monitor also provides a timer mechanism 
to allow serveiS to schedule a call to be issued at a later 
time. This functionality is provided transaclionally so that 
the call made within the scope of a transaction is scheduled 
if the transaction commits. The call does not occur if the 
transaction aborts. 

The Encina/9000 monitor provides support for application 
developers who wish to integrate their Encina/9000 client 
with forms-based user interface tools. Encina/9000 is inte- 
grated with JAM, a forms-based tool from JYACC Inc. 

In summary, the Encina/9000 monitor provides the following 
benefits: 

Simplified programming for writing clients and servers 
Automatic detection of failures and restarts of monitor 
daemons and PAs 

Automatic load balancing between clients and servers 
Collection of statistics by the monitor for server use 
.Simplified central place of administrat ion for distributed 
clients and servers 

Support for highly concurrent access to relational data- 
bases. 

Standards Supported by Encina/9000 

Encina/9000 supports the following standards: 
X/Open: 

XA 

TX 

TxRPC API 

CPI-C 

ISAM 
SAA: 

CPIC 

CP1/RR 
OSF DCE. 

Encina/9000 interoperates with the following products: 

Oracle 

Informix 

Ingres 

Sybase 

Open CICS 

IBM mainframe CICS 

IBM mainframe IMS/DC. 

The Encina/9000 toolkit has been used to support other 
transaction processing products and provide the base func- 
tionality to support other products like Open CICS and 
STDL each running on top of Encina/9000 on the HP-TIX 
operating system. 



Value-Added Features 

HP Encina/9000 provides value-added features in the areas 
of system administration and high availability. 

System Administration 

An Encina/9000 system administrator must configure the 
Encina cell and define the administrative interfaces for the 
various servers in the system. 

All Encina cell must be closely tied to a logical administra- 
tive unit of work, and the data accessed to do this work 
should be in the same cell. It is possible for applications to 
intemperate across Encina cells using explicit bindings. 
Therefore, the exact boundaries of an Encina cell must be 
defined by carefully analyzing the applications miming in 
the system with careful consideration being given to secu- 
rity, number of users and machines, location of data, and the 
applications that access the data. 

A system administrator must create the log space used by 
Encina/9000 and then bring up the following Encina/9000 
components: 

• Structured file system 

• Cell manager 

• Node manager 

• Servers such as the recoverable queueing service and the 
PPC gateway if they are needed 

• The requited application servers. 

Encina/9000 provides administration tools for the following 
components: log, structured fill' system, monitor, recover- 
able queueing service, PPC, and the rest of the toolkit. These 
tools provide the appropriate low-level commands for ad- 
ministering these components. Encina/9000 also provides a 
perl-based tool called encsetup, which provides higher-level 
system administration facilities. The HP value-added system 
administration facilities are described later in this section. 
Finally, Encina/9000 also provides libraries for developing 
system administration products, which are very useful for 
customers dev eloping these kinds of products. 

Encina/9000 system administration is very closely tied to 
DCE system administration. The DCE cell must be config- 
ured before the Encina cell can be configured. Eneina/9000 
also makes use of the DCE directory service. The default 
Encina root cell directory is defined as /.:/encina (this default 
can be changed if needed). Encina/9000 components regis- 
ter their name under this directory; Within this directory 
there are directory entries for the recoverable queueing ser- 
vice, the structured file system, the Encina/9000 monitor, 
transactional RFC, and peer-to-peer communication (PPC). 
For example, each recoverable toolkit server registers an 
entry in the /.:/encina/trpc directory (trpc = transactional RPC). 
and each recoverable monitor server registers an entry in 
the /.:/encin3/tpm/trpc directory (tpm = Encina/9000 monitor). 

The use of the directory allows the Encina/9000 system 
administrator to restrict access to various resources. The 

' Peri (Practical Ertracnon Report Language) is a UNIX programming language that is designed 
lo handle system administrator (unctions 
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system administrator can use DCE tools like ad_etJrt to grant 
a user, a group, or an organization permission to access a 
particular resource. Encina/9000 uses the DCE authentica- 
tion and authorization mechanisms to maintain security. An 
Encina/9000 server can specify the level of authorization a 
user of the server must have to access that server. A client 
wishing to access a secure server must be authenticated with 
DCE and when the client calls the server, the server uses the 
DCE security mechanisms to verify whether it should allow 
access to the user. DCE access control and security are dis- 
cussed in the articles of pages 4.9 and 41 respectively. 

IIP provides a DC AM layer for Encina/9000. DCAM stands 
for distributed computing application management. DCAM 
is an architecture and methodology for providing uniform 
system management for products that enable distributed 
computing such as DCE. Encina/9000, and ('ICS. An advan- 
tage of DCAM is that ii provides a consistent look and feel 
for all of these products to the user and aids in the overall 
ease of use of these products. It provides a graphical user 
interface as well as a DCAM shell. DCAM provides a set of 
action verbs that can be modified by options and operate on 
objects. 

Fig. 12 shows the relationship between the DCAM ( LI 
(command-line interface) layer, the DCAM shell, and SAM 
(system administration manager). 

SAM is a menu-driven interface used to manage an Encina/ 
9000 system. The DCAM shell is a command-line interface 
which can be used to type in administrative commands. 
SAM and the DCAM shell are layered on top of the DCAM 
CLI scripts which convert the DCAM commands to native 
Encina/9000 administration commands. 

The common look and feel provided by DCAM enables a 
system administrator to manage the different distributed 
systems and applications based on DCE with a consistent 
and user-friendly interface. DCAM does this by providing 
consistent use of vocabulary to represent actions. The con- 
sistent use of syntax and semantics is import ant because of 
the different subsystems thai DCAM is built upon. The con- 
sistency provided by DCAM improves user efficiency and 
lowers error rates. 

DCAM provides a natural way for system administrators to 
express the actions that they want. For example, to create a 
structured file system server, a system administrator would 
type the command: create stssen/er. This command is converted 
by DCAM to the underlying Encina/9000 low-level commands 
needed to create the server. 
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Fig. 12. System administration tools with DCAM 



The SAM interface of DCAM is more useful for people who 
are familiar with SAM or are getting acquaint ed with Encina' 
!'("i(i Hi.' DCAM shell is generally used for efficiency by 
experienced Encina/9000 system administrators, hi addition, 
the DCAM shell is also used for writing and customizing 
system administration scripts. 

DCAM is object -oriented. Objects represent items that can 
be encapsulated and acted upon. Encina/9000 objects can be 
an Encina cell, a server, or a transaction. Objects have attri- 
butes. For example, a structured file system server lias an 
associated attribute that describes the log volume associated 
with the server. Actions are verbs that act upon the objects. 
For example, the actions create, start, modify, and stop can 
be used to act upon an object. Actions have object indepen- 
dent semantics in that they have similar semantics regardless 
of the type of object they are w orking on. For example, the 
verb create can be used to create an Encina cell, a structured 
file system server, an application server, and so on. Actions 
have options. An action can be specified with the default 
options, or the administrator can specify task-specific op- 
tions with the action. 

A task defines a pairing of an action with an object. A task 
consists of one action, one object, zero or more options, and 
one or more attributes. For example, start cell -Name name, 
which tells DCAM to start up the named cell along with 
other optional parameters, is a task that can be specified 
with the DCAM shell. If the parameters are not specified, the 
DCAM shell will prompt for the parameters. In SAM. the 
parameters are displayed as fields in the SAM panel and can 
be entered. If the required parameters are not entered, an 
error is displayed. 

Another useful feature of DCAM is the help facility, Which 
can be used by the system administrator to interactively 
obtain help on a topic. This is also useful for someone who 
is learning Encina/9000 administration since it lists ihe vari- 
ous alternatives and options to a command and provides an 
easy way for administrators to get a feel for the various 
commands and opt ions. 

To many users the real value of DCAM is the added capabili- 
ty it has thai go beyond what native Encina/!)! MM) adminis- 
tration supports. This includes high-level server configura- 
tion tasks which are much easier, complete support for 
transparent remote configuration from anywhere in the DCE 
cell, autorestart of toolkit servers like the structured file 
system and the recoverable queueing service, and support 
for ServiceGuard/CX's failover" feature. 

High- Availability Features 

Many customers have a strict requirement for data to be 
available at all times. Data replication with Encina/9000 can 
be provided by the use of dala mirroring with mirrored 
disks. In addition, to provide dala availability in Ihe case of 
machine failures, Encina/9000 can be integr.il ed with the 
Swilchover/L'X and the ServiccGuard/l'X products (de- 
scribed below). These products allow node failures to be 
handled, and they provide a sel of scripts that facilitate the 
administration of a highly av ailable system. 

• Failnvm relers M tht process that occurs when a standby node lakes over Irom a failed node 
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In a distributed system there can lie many causes of failures, 
and failures of disks, networks, and machines can all impact 
availability. Since the system is composed of several nodes 
connected with network links, there are more points of fail- 
ure (hat could impact availability. Network failures are not 
described here, but users who need highly available Encina/ 
9000 applications should try to avoid single points of net- 
work failure. 

Many techniques exist for dealing with disk failures. The 
preferred method of dealing with disk failures is to use 
HP-UX nihioied disks with a logical volume manager. Other 
choices are to use RAID" or to use Encina/9000 mirrored 
disks. The advantage of the HP-l'X mirrored disk technique 
is that it is a general-purpose solution with applicability to 
all kinds of data like the structured file system and DBMSs. 
If the database can handle the logical volume manager con- 
figured for no consistency then it should be used for data- 
base data. Minor write consistency, or mirror consistency, 
should be used for Encina/9000 data or for database data 
that can handle consistency mirroring. RAID can be used as 
a relatively inexpensive solution to handle disk failures, bm 
it has many single points of failure in the disk I/O path and is 
not good for the short random write updates that are typi- 
cally found in transaction systems. Encina/9000 mirroring 
has the disadvantage that it is not integrated in the HP-UX 
Operating system and can therefore only be used for Encina/ 
9000 data and not for, say, DC'E or DBMS. Its advantage is 
that it can automatically handle more failure conditions than 
HP-UX mirroring. Encina/9000 mirroring is slower than 
HP-UX mirroring, but it has a faster recovery lime. 

There are two primary solutions for node failures: Switch- 
over/I 'X and SeiviceGuard/UX. In Switehover/UX, a primar y 
node and a standby node are configured with mullihosted 
disks. The primary node runs in the normal case. 'Die standby 
node is also connected to the disks and uses a heartbeat 
protocol to detect failure of the primary node. When the 
standby node detects that the primary node has failed, it 
assumes the primary node's identity b\ booting off the pri- 
mary node's disks and using the primary node's IP address. 
The standby node then uses the primary node's disks to re- 
boot and to restart the system processes and applications. 
This allows a fast restart after the primary node has 
crashed, resulting in a small downtime. The primary and 
standby nodes should be from the same hardware family. 

With Switchover/UX the Encina/9000 processes are restarted 
when the standby node reboots. Using Eneina/9000's trans- 
parent binding, clients are automatically reconnected to the 
servers. However, in this case client transactions will keep 
aborting until the failover is complete. 

In ServiccGuard/UX. applications and data are encapsulated 
as packages that can be run on various nodes of a cluster. 
ServiceGuard/UX allows the user to define the packages, 
and each package has a prioritized list of nodes it can ran 
on. SeniceGuard/UX ensures that a package only runs on 
one node at a time. A package is defined by a startup/shut- 
down script and can represent any application. The nodes 
l imning packages monitor each other's status and restart 
packages when they detect the failure of another node. 

A package can be an Encina/9000 application server running 
under a single Encina/9000 node manager. The package can 



also include assorted toolkit servers like the structured file 
system, a recoverable queueing service, or an Encina/9000 
monitor. ( )ptionally, a package can have one or more IP ad- 
dresses. If specified, a package's IP address is associated 
with the network interface on the machine currently execut- 
ing the package. With ServieeGuard/UX a user can configure 
a simple failover scheme. The user can also define a single 
package that can execute on a primary or a backup node. 
This scheme is general and can be used for the Encina/9000 
log. structured file system, recoverable queueing service, 
monitor, and DBMS and DUE core servers. 

Encina/9000 servers can be integrated with ServiceGuartl/ 
UX. In this case the Encina/9000 servers should be config- 
ured in a ServiccGuard/UX cluster, and a package should be 
created for the servers. The package should contain run and 
halt scripts for the servers, which specify the actions to take 
when a package is started or terminated. The actions in a 
run script include adding the relocatable IP address to the 
network interface, mounting all logical volumes, and calling 
an Encina/9000 script to start all the Enema/9000 servers. 
The actions in a halt script include calling an Encina/9000 
script to hall all the Encina/9000 servers, unmounting all the 
logical volumes, and removing die relocatable IP address. 

ServiceGuard/UX offers a more flexible solution for high 
availability. It can be configured with a dedicated standby 
solution similar to Swilchover/UX, or it can be configured in 
a more duster-like configuration. It also has a faster recov- 
ery time since failover nodes do not need to reboot. 

Encina/9000 also provides the ability to perform application- 
level replication of data. An alternative to application-lev el 
replication is the replication of data provided by databases. 
Database-level replication has the adv antage of being t rans- 
parent to the user, and it is relatively efficient. Application- 
level replication, on the other hand, is less dependent on 
specific DBMS platforms and can be used to provide replica- 
tion across DBMS platforms. In addition, it is more flexible 
and can be performed in a synchronous or asynchronous 
manner. It may be important to perform asynchronous repli- 
cation across a WAN to achieve a faster response time. The 
disadvantage of application-level replication is I hat the ap- 
plication developer must design and implement the replica- 
lion scheme. 

An example of replication using Encina/9000 is master/slave 
replication of data with deferred updates to the slave. In this 
scheme, the master copy of the database is maintained on a 
machine. The application updates the master database and 
stores a copy of the update in the recoverable queueing 
service. With this setup the application can Iransactionally 
update the master database and store a copy of the updates 
in the recoverable queueing service. At a later time the data 
is iransactionally dequeued from the recoverable queueing 
service and applied to the slave database on another ma- 
chine. The strength of this approach is that the two ma- 
chines holding copies of the data do not have to be running 
at the same time, and the update can be deferred to a time 
when the load on the system is low. It also avoids having to 
do online a two-phase commit across the machines. How- 
ever, there is the drawback that the replica is not consistent 
with the master, and the updated data would be unavailable 
while the master node is down. 
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Encina/9000-Based Architectures 

Some of the common Encina'9000-based architectures in- 
clude corporate centralized data architecture, region 
centralized data architecture, and branch data arclutecture. 
In each of these architectures we consider a corporation to 
In- an entity thai has a central data processing center located 
at its headquarters The corporation's business is geograplu- 
cally spread over several regions, and each regional center 
has a data processing center. Each region also contains mul- 
tiple branch offices, and the branch office has a number of 
users who are executing transactions, in the past, compa- 
nies employed mainframes at the corporate headquarters, 
where all the data was maintained. This was expensive to 
maintain, and the response time got worse as the data on 
the mainframe increased. 

In a corporate centralized data architecture data is still 
maintained at the mainframe host. Connection to the main- 
frame is through gateway machines that run the Encina/9000 
PPC executive. Depending on the availability requirements, 
the gateway machines could be implemented with the high- 
availability solutions mentioned earlier. One option would 
be not to have any machines at the branch offices or the 
region offices but rather to have PC's at these offices which 
talk directly to the mainframe. Alternately, I he regional cen- 
ters or the branches could have machines, add the regional 
machine could route a request from a branch to the corpo- 
rate center. All the data is maintained at the corporate cen- 
ter and there is no local business data at either the regional 
offices or the branch offices. This architecture is shown in 
Fig. 13. 

This architecture is useful if it is hard to replace the main- 
frame machines and data. Alternately, it may be possible to 
offload some of the data from the mainframe to machines 
running the HIM X operating system at the corporate data 
center. 

The regional centralized data architecture is similar to the 
corporate centralized data architecture, except that the data 
is partitioned across the regional data centers. The data 
could also be stored with the mainframe at the corporate 
data center. Clients can run at the branch machines or at the 
regional center. Optionally, there could be a database at 
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Regional OHice 



either the corporate center or the regions that assists in 
routing a request to the appropriate regional center. This 
architecture is shown in Fig. 14. 

In the regional centralized data architecture. Encina/9000 
servers typically run on the regional machines. Clients can 
run at the branch or regional offices. Clients employ lookup 
mechanisms to locate the appropriate server and then make 
calls to the servers. An Encina/9000 PPC can be used to 
transactionally read or update data stored at the corporate 
center. 

The regional centralized data architecture has the advantage 
of avoiding GPU bottleneck problems when a large number 
of transactions have to be processed on a single database. 
Since the databases are spread throughout the regions, they 
all can handle transactional access to the data allowing a 
higher volume of transactional traffic. In addition, if users 
frequently access data at the nearby regional center, net- 
work traffic will be localized. 

In the branch data arcltitecture. each branch maintains its 
local branch data. The data can also be aggregated and 
maintained at the corporate center, but users primarily ac- 
cess the data at a branch machine. Optionally, corporate or 
regional centers can maintain a cross-reference database to 
assist with routing a user request to the appropriate branch. 
Tltis architecture is shown in Fig. 15. 

The main advantage of this solution is the fast response time, 
since for most transactions data can be looked up locally 
and expensive two-phase commits over the WAN can be 
minimized. The drawback of this scheme is having to main- 
tain a large number of databases and administering ihem. 

Conclusion 

The Encina/iMIOI) product provides an application develop- 
ment environment for developing < >I,TP applications and the 
run-time support for running and administering the applica- 
tions. Its strengths are the flexibilitj it provides for distrib- 
uted < >LTP applications compared to the traditional data- 
base products, and its strong integration with the IIP In I', 
product Ii provides an infrastructure for customers to write 
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reliable and secure applications for their mission-critical data. 
Additionally, the EminaAiOlili product provides added value 
in the areas Oft system administration and fault tolerance. 
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Object-Oriented Perspective on 
Software System Testing in a 
Distributed Environment 

A flexible object-oriented test system was developed to deal with the 
testing challenges imposed by software systems that run in distributed 
client/server environments. 

by Mark C. Campbell, David K. Hinds. Ana V. Kapetanakis. David S. Levin, Stephen J. McFarland, 
David J. Miller, and J. Scott Southworth 



In recent years Software technology has evolved from 
single-machine applications to multiniacliine applications 
(the realm of the client and server). Also, object-oriented 
programming techniques have been gaining ground on pro- 
cedural programming languages and practices. Recently, 
test engineers have focused on techniques for testing ob- 
jects. However, the design and implementation of the test 
tools and code have remained largely procedural in nature. 

This paper will describe the object testing framework, which 
is a software testing framework designed to meet the testing 
needs of new software technologies and take advantage of 
object-oriented techniques to maximize flexibility and tool 
reuse. 

System Software Testing 

The levels of software testing include unit, integration, and 
system testing. I'nit testing involves testing individual system 
modules by themselves, integration testing involves testing 
Che individual modules working together, and system testing 
involves testing the whole product in its actual or simulated 
operating environment. This paper focuses on software 
system testing. 

A software system lest is intended to determine whether the 
Software product is ready to ship by observing how the 
product performs over time while attempting to simulate its 
real use. System testing is composed of functional, perfor- 
mance, and stress tests. It also covers operational, installa- 
tion, and usability aspects of the product and may include 
destructive and concurrence testing. The product may sup- 
port many different hardware anil software configurations 
which all require testing. All of these aspects are combined 
to assess the products overall reliability. Software system 
testing is usually done when all of the individual software 
product components are completed and assembled into the 
final product. 

In the past, system testing environments centered around 
testing procedural, nondistrlbuted software. These environ- 
ments, which were also procedural and nondisiribuled, 
were usually developed by the lest writer on an ad hoc basis 
along with the lesl code for the product. Recently, software 
system testing has benefited from the use of highly auto 
mated lest harnesses and environments that simplify lesl 



execution, results gathering, and report generation (see 
Fig. 1 ). Unfortunately, the test harnesses created in these 
environments were not easily reusable, and when the next 
project reached the test planning stage, the test harness had 
to be reworked. 

The adv ent of standardized test environments such as TET 
(Test Environment Toolkit )* helped to reduce this costly 
retooling by providing a standard API (application program 
interface) and tool base that test developers can adopt and 
use to write standardized tests. However, the difficulty is to 
provide a standard test harness that is complete but flexible 
enough to keep pace with changing software technology and 
remain viable for the long term. 

During the development and testing of the initial release of 
HI' ( >RB Plus, which is an object request broker based on 
the Object Management Group's t'ORBA specification (see 
page 7ti). we realized that distributed object technology 
posed lesiing problems that were not adequately solved by 
any of the test harnesses currently av ailable. We needed a 
flexible lest environment that could handle heterogeneous 

' rim lesl Environment Toolkil (TET) specification began m September 198B as a jomi proposal 
bv trie Open Software Foundation. UNIX'"' International, anil X/Open " 
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distributed systems communicating over multiple transports 
using multithreaded clients and servers. However, we were 
not willing to lose the investment we made in the lesl code 
and loots developed for our earlier products. 

Instead of abandoning the old test environment and replac- 
ing it with an entirely new system, we dec ided to use the 
object -oriented principles of encapsulation and polymor- 
phism to evolve our current environment base to meet our 
needs without throwing out the old code. The ability to 
Change or replace funct ional blocks of a system without 
affecting the entire environment is one of the main hem-fits 
of object-oriented design (see "Object-Oriented Program- 
ming" on page 79). Object-oriented principles allowed us to 
reuse existing tools. 

Distributed System Testing 

In a distributed object system, service providers are distrib- 
uted across a network of systems and are called servers. 
Clients, who issue requests for those services, are also dis- 
tributed across a network. A single program can be both a 
client (issues requests) and a server (services requests). 
( 'lienls can issue requests to local and remote servers. Dur- 
ing a distributed object system test, clients are responsible 
for reporting any failures or status resulting from the re- 
quests I hey make. 

The first task performed during the system testing of a dis- 
tributed object software product is test setup. Clients and 
servers must be deployed across the network to largeted 
Systems. Consideration must also be given to the fad I ha! 
servers may have multiple clients sending messages to them, 
and the distribution of clients and serv ers may change dur- 
ing a system lest so that various hardware and soli ware 
configurations can be tested. 



The Object Management Group's 
Distributed Object Model 

The Object Managemem Group I0MGI creates standards for the interoperability 
and portability of distributed object-oriented applications The OMG only produces 
specifications, not software Each participating vendor provides an implementa- 
tion to meet the specification. The Common Object Request Broker Architecture 
ICORBA) specification defines a flexible framework upon which distributed object- 
onented applications can be built. This architecture represents the Object Request 
Broker I0RB) Technology that was adopted by the OMG An ORB provides the 
mechanisms by which distributed objects transparently make requests and receive 
responses. The ORB enables object-oriented applications on different machines to 
communicate and interoperate. 

The OMG has defined an Object Management Architecture object model In this 
model, objects provide services, and clients issue requests for those services. The 
ORB facilitates this model by delivering requests to objects and returning any 
outpul values to the client The services that the ORB provides are transparent to 
the client. 

To request a service, a client needs the ob|ect reference for the ob|ect that is to 
provide the service The ORB uses this object reference to identify and locate the 
object The ORB activates the object if it is not already executing and directs the 
request to the object 



When test clients execute, they are instructed to run for a 
specified amount of time. They report failure and status in- 
formation back to a central location. Upon completion of 
Ihe system lest, clients and servers are stopped, temporary 
files are removed, and final summary reports are produced. 

The Test System 

To manage all the activities of distributed system testing we 
developed a test infrastructure that met our current needs 
and could evolve with new technologies and new needs. We 
followed a modular, object-oriented design approach to 
accomplish this. 

We first engaged in several brainstorming sessions to pro- 
duce a list of requirements for a complete distributed testing 
framework This was an attempt to pinpoint all the attributes 
and functionality that a "perfect" test infrastructure would 
have, and it was done in Ihe context of system testing dis- 
tributed objects. The needs of product developers, lesl de- 
velopers, and testers were considered, as well as the need to 
report metrics to the project leant. The main focus, however, 
was on the two groups who would use the test framework 
the most: test developers and testers. Oil en these are the 
same people, but the distinction was made to clearly differ- 
entiate the needs of each group. 

Product developers normally want quick and simple tests to 
verify that their code behaves correctly and at the same time 
have their programs work as they would for an end user. 
They don't w : ant to be distracted by ihe infrastructure. Exist- 
ing lest APIs tend to be intrusive, requiring developers to 
have knowledge of the test environment in which their tests 
will he run. Therefore, we wanted otu - new test framework 
to minimize intrusiveness. This would allow developers to 
focus on testing Ihe proper behavior of their code and not 
on the test infrastructure. Ideally, product developers should 
be able to write their tests with minimum restrictions, and 
the tests should plug and play in many different testing 
sil nations. 

Test developers, whose job il is to develop ways to lest the 
product, have many of the same needs as product develop- 
ers but are more concerned with black-box testing and try- 
ing to "break" the product rather than verifying correct be- 
havior. To do this, test developers want to be able to plug 
new tests into the test environment easily and quickly, and 
they want process and environment control. This would 
allow them to use the same tests in different scenarios to 
find more product defects. Test developers are usually the 
ones responsible for supporting the testing infrastructure. 
Thus, more than any of the other groups, test developers 
need a framework that is extensible, reusable, flexible, and 
controlled, and hopefully has a long lifetime. If a testing in- 
frastnicture becomes out of date, test developers will have 
to repair or replace it. 

Often test developers are the ones who perform system test- 
ing, but many times this role is handed off to testers. Although 
the needs of both groups clearly overlap, testers need a test- 
ing infrastructure that is easy to use for the installation, con- 
figuration, and execution of tests. In many of our past proj- 
ects, testing was done by temporary personnel. This freed 
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test developers to write more tests and assist product devel- 
opers in debugging. When the test infrastructure is easy to 
use. the testing role can be handed off to testers earlier in 
the testing process. Additionally, the ability to reconfigure 
the test environment easily and quickly allows more scenar- 
ios to be tested. This increases the likelihood of finding more 
product defects, which leads to a better quality product. 

Finally test results are usually provided to the project team 
in the form of metrics. Gathering metrics in a distributed 
environment can be time-t-onsuming. Data can be located on 
multiple systems on the network. However, when dealing 
with multiple processes running in parallel on different sys- 
tems, results may not always occur in a consistent order. 
This implies the need for a centralized repository for testing 
results. This would make the generation of metrics much 
easier and faster, while providing a central location for End- 
ing problems and debugging. 

Design Methodology- 
Taking into consideration the needs of the different groups 
mentioned above, we decided that the following attributes 
were required for our test infrastructure. 

• Extensibility. Ensure the evolution of a modular system that 
can be dealt with on a component-by-component basis. 

• Reusability. Allow object and code reuse for both tests and 
the test infrastructure. 

• Flexibility. Provide a plug-and-play environment thai allows 
for flexibility in test writing and configuration. 

• Simulation. Provide the ability to simulate customer 
environments. 

• Control. Provide centralized control of the test processes 
and environment 

• Nonintrusive. Hide as much of Ihe testing infrastructure as 
possible from the system under I est. 

• Ease of use. Provide ease of use for installation, setup, con- 
figuration, execution, results gathering , and test distribution. 

Willi these attributes in mind, we set about deciding on the 
basic sel of classes that would be needed. We used a method 
for object -orienled design called < )bjecl Modeling Technique 
(OMT) 1 to develop a diagram showing class relationships 
(see "Object-Oriented Programming" on page Til). 

We walked through several scenarios and expanded and 
refined our set of classes. Once we had an initial design we 
wrote CRC (class, responsibility, and collaboration)- cards 
for each of the classes in our design. (CRC cards are also 
described on page 79.) This design was reviewed by Ihe 
produc t development learn and their feedback was incorpo- 
rated. 

The Object Testing Framework 

The design process produced an object-oriented software 
testing system thai We named the object testing framework 
(OTF). Although this design is intended to test distributed 
object-based software, it can also be used to lest distributed, 
procedurally based client/server software. 'Hie OTF consists 
of the classes shown in Fig. 2, The architecture of the OTF is 
such thai there is a single master lest conlrol system (OTF 
management system in Fig. 2) that orchestrates running 
tests on multiple systems under lest. This master system can 
also be :i system under test. 



In the following design discussion, the lerni object can mean 
class or an instance of a class. It should be clear from the 
context of the discussion which is meant. 

OTF Management System 

The OTF management system consists of the six major 
classes: user interface. OTF controller, test suite configura- 
tion, test controller, report generator, and database control- 
ler. This system provides the user interface that the software 
tester interacts with. Through this interface the tester speci- 
fies test configurations such as which client and server pro- 
grams will be running on which St'Ts. The OTF management 
system takes the specified configurations and makes then) 
available to each of the SITs. ensures that the SITs run the 
specified tests, logs test data and results, and generates test 
reports. 

The main class in the OTF management system is the OTF 
controller, which serves as the delegator object. It takes 
requests from the user interface object and manages the 
activities of the test suite configuration, test controller, and 
report generator objects. The test suite configuration object 
is actually created by the OTF controller. For a new configu- 
ration the object will initialize from the configuration data 
provided by the user interface. For a previously specified 
configuration. Ihe object will initialize from the database. 
After this object's configuration data has been set, its pri- 
mary responsibility is to respond to configuration queries 
from the SUTs. 

The test controller has Ihe overall responsibility for coordi- 
nating the running of tests on the SI'Ts. It provides Ihe SITs 
with a pointer to the test suite configuration object, synchro- 
nizes the starting of tests, and passes status data and re- 
quests back to the OTF controller. It also has the capability 
to log status data to the database via the database controller. 

The report generator, upon a request Erora the I >TF control- 
ler, queries Ihe database controller to assemble, filler, and 
format test data Into user-specified lesl reports. Raw lesi 
data is put into the database by each SUTS TestEnvironment 
object, while test process status data is put into Ihe data- 
base by the test controller as mentioned above. 

System under Test 

Each system under test (Sl.T) contains fifteen classes. In 
normal operation, a SI T retrieves configuration data from 
the OTF management system, and then, based on that data, 
retrieves the specified tests from the management system. 
Since the SUT has the capability to build test executables 
from source code, it can retrieve test source code and exe- 
cutables from the OTF management system. Once the test 
executables are in place and any specified lest setup has 
been completed, the SIT waits for a management system 
request tO Start Ihe tests. When this happens, the SIT is 
responsible for running the tests, logging slat us, lesl data, 
and results, and cleaning up upon test completion. 

The main object in the SUT is Ihe host daemon, which is Ihe 
SL ; Ts delegator object. The host daemon lakes requests 
from and forwards requests to the < >TF management system 
and manages Ihe aclivilies of the seller upper, lesl executor, 
cleaner upper, process controller, and TeslEnvironmeni objeels. 
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The overall responsibility of the setter upper, test executor, 
and cleaner upper objects is to manage how the tests are 
run. These three objects collaborate with the builder, test 
distributor, checker, and factory TestCase objects to form the 
test management subsystem shown in Fig. 2. The process 
controller and TestEnvironment objects provide the infrastruc- 
ture for connecting the tests to the framework. These Iwo 
objects collaborate with the TestCase objects to form ihe 
process management subsystem. 

Test Management Subsystem 

This subsystem sets up and executes the tests and then 
cleans up after the tests have completed. The setter upper is 
the object thai controls test setup. It is a low-level delegator 
that manages the activities of the builder, test distributor, 
checker, and factory- TestCase objects. The lest distributor is 
responsible for retrieving lest executables and sources from 
the OTF management system. When it retrieves source 
code, the builder is responsible for generating test execut- 
ables from the code. How the tests are retrieved depends on 
the overall system environment and resources available. A 
distributed file system, like NFS, could be used, or the tests 



Fig. 2. System nrchiferUire I'm tilt; 
object testing framework. 

could be remote copied from the management system to the 
SUT. An important design consideration was to have a single 
repository for tests. This makes it easy to control changes to 
tests and is not intrusive on the SUTs. 

The checker provides the ability to customize test setup by 
invoking a user-written program that can ensure that ele- 
ments outside of the test environment are set up correctly. 
For example, it could check that NFS and DOE are running, 
that the display is set correctly, and so on. 

The factory- TestCase provides the setup procedures that arise 
when testing a CORBA-based distributed object system. It 
creates the CORBA objects that reside in the CORBA-based 
server TestCases and stores references to these objects for 
use by the client TestCases. The factory TestCase class inherits 
from the TestCase base class and the lest developer writes a 
class thai inherits from the factory' TestCase class. This allows 
the test developer to customize the factory TestCase function- 
ality for a specific test. 

The lest executor object stans the client TestCases through 
the functionality inherited from the TestCase base class. It 
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OTF API is made available through the pointer to the TestEn- 
vironment class pro\ided by the base TestCase class. 



Object -onemefl programming is a set of tecnntques for creating objects and as- 
sembling mem into a system that provides a desired functionality. An object is a 
software model composed of data and operations An object's operations are used 
to manipulate its data Objects may model things such as Queues, stacks, win- 
dows, or circuit components When assembles) into a system, the objects function 
as deiegators, devices, or models Messages are passed between the objects to 
produce the desired results 

The eventual goal of object-oriented programming is to reduce the cost of soft- 
ware development by creating reusable and maintainable code This is achieved 
by using three features of object-oriented programming encapsulation, polymor- 
phism, and inheritance Encapsulation consists of data abstraction and data hid- 
ing. Data abstraction is a process of isolating attributes or qualities of something 
into an ob|ect model With data hiding an ob|ect may contain us own private data 
and methods, which it uses to perform its operations By using polymorphism, an 
object's operation may respond to many different types of dala (e.g.. graphical and 
textual) Finally, using inheritance, an object can inherit attributes from other 
objects The ob|ect may then only need to add the attributes, methods, and data 
structures that make it different from the obiect from which it inherited its basic 
characteristics 

For the design of the object testing framework described in the accompanying 
article, we used an object-oriented software design methodology called object 
modeling technique I0MT) This methodology provides a collection of techniques 
and notation for designing an object-oriented application. 

One important aspect of object-oriented design, or any software design, is decid- 
ing on who (i.e., module or object] is responsible for doing what. A technique 
provided in OMT involves using an index card to represent ob|ect classes. These 
cards are called CRC (class, responsibility, and collaboration! cards. The informa- 
tion on one of these cards includes the name of the class being described, a 
description of the problem the class is supposed to solve, and a list of other 
classes that provide services needed by the class being defined 



also reports hack l" I lie llosl daemon I lie success or failure 

of a test start., 

The cleaner upper cleans up after the tests have completed. 
This may include removing temporary files, removing test 
executables, and so on. 

Process Management Subsystem 

The two main objects in the process management subsys- 
lem are the process controller and TestEnvironment objects. 
The process controller has the overall responsibility lo mon- 
itor all test-related processes on the SIT. It can regisler or 
unregister processes, kill processes, and report proc ess sla- 
ms back lo the host daemon. 

The TestEnvironment class provides the (est developer with an 
application programming interface to the OTF. It provides 
methods for aborting tests, logging test data and results, 
Checking for exceptions, getting environment variables. ;unl 
so on. The lest developer gels access lo these methods 
through the base TestCase class, which has an association 
With Che TestEnvironment class. 

I ivalinji a lest involves writing a class that inherits from 
either the client TestCase or server TestCase base classes. The 
initialization and setup functionaliiy for the lest would be 
included in the test's constructor. The cleanup required 
when the lest is done is included in the destructor. Finally, 
an implementation for the inherited run_bodyf) method is 
included, which is the test executable that runs the lest. The 
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Implementation Approach 

Once the design was complete, an initial investigation was 
made to find an existing system that matched the character- 
istics of the design. When no system was found, an analysis 
was done to determine the cost of implementing the new 
infrastructure. 

it quickly became obvious that the transition to the new 
infrastructure would have to be gradual since we did not 
want to impact the HP ORB Plus product release cycle. The 
flexibility provided by an object-oriented system enables 
gradual migration and evolution through encapsulation, 
inheritance, and polymorphism. Tests could be isolated from 
the infrastructure so that new tests could be developed and 
evolved without modification as the infrastructure evolved. 
This flexibility fit nicely with the realization that the time to 
replace the existing infrastructure exceeded an average 
product life cycle. 

Object-oriented encapsulation provided another advantage. 
Once some basic changes were made to the existing test 
infrastructure and tests had been converted to the new 
object-oriented programming model, the existing test infra- 
structure could be used lo simulate some aspects of the new 
infrastructure. This allowed our system testing efforts lo 
benefit immediately from the features of the new lest 
system. 

The development of the current version of lite object testing 
framework lias taken place in two steps, which have spanned 
three releases of the HP ORB Plus product At each step we 
have continued to apply the same design principles. This 
work is summarized in the following sections. 

First Step For the first step, the goal was to consolidate the 
best practices of three existing lest infrastructures into a 
single infrastructure that simulated as much Of the major 
functionality of the OTF as possible. So as not to impact the 
ongoing I IP ORB Plus software releases, another goal was 
to minimize changes to existing lest code. This resulted in 
an infrastructure t hat consisted of a layer of shell scripts on 
top of two existing lest harness tools. This significantly re- 
duced the effort needed to set up. administer, and update 
the network of systems that were used lo system test the IIP 
ORB Plus product, while the tests continued to use existing 
APIs, It also confirmed that our design was indeed trying to 
solve the right problems. 

Second Step. For this step ilie goal was to deploy the lest 
developer's API lo the ( >TR The result was the implementa- 
tion of the C++ TestEnvironment and TestCase classes described 
above. 

Additional classes were designed to connect the TestEnviron- 
ment and TestCase classes to the existing infrasiriiciure. Inn 
their existence is hidden from the test developer. This pro- 
vides a stable API Without limiting future enhancements to 
the infrastructure. Once the new infrastructure was deployed) 
we focused on porting existing tesls to it. 

This framework has resulted in minimal changes to existing 
tests and maximum increase in functionality for the tests. 
Most of the work simply involved taking existing code and 
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wrapping 11 in I ho appropriate class. All of our tests have 
benefited from the features provided by the TestEnvironment 
and TestCase classes and are insulated from changes to the 
framework. 

At this stage of its development the object testing frame- 
work allowed the removal of intrusive test code required by 
the old test APIs. For example, many tests included code 
thai allowed a test to be rcexecuted for a specific lime pe- 
riod. Thai code was removed from the lesls because ihe 
same functionality is now provided by Ihe framework. 

In addition to supporting the design shown in Fig. 2, our 
current implementation provides Ihe following functionality: 
Deration. A test can be executed repetitively, either by spec- 
ifying a number of iterations or the amount of time. 
Context-sensitive execution. The object testing framework 
behaves diffcrenilj depending on how ii is invoked. In the 
developers environment it is transparent and does not 
affect test behavior, hi the testing environment it is bound 
to the tesl system. For example, in the developer environ- 
ment, the C+ + functions cerr and cout go to the terminal, but 
in the testing environment they go to a file and the tesl re- 
port journal respect ively. This encourages developers to put 
all existing tests into the framework because the test con- 
tinues to work the way it did before it was ported. 
Simple naming service. A naming service allows the user lo 
associate a symbolic name with a particular value such as 
the path name of a data file. In a distributed system, it is 
necessary for multiple processes lo share values that are 
obtained outside of the system — for example, object 
references. 

Automatic capture of standard output streams cout and cerr. 
To simplify porting of existing lests, the cout and cerr 
streams are mapped to a file and ihe journal file 
respectively. 

Encapsulation of functions from ihe product under test. For 
example, the pails of CORBA used by the tests are encapsu- 
lated. As ( "( >RBA evolves and changes its C++ language 
bindings, only a single copy of ihe bindings in the frame- 
work has to change. 

Inheritance and reuse. Inheritance allows ihe test case de- 
veloper to describe similar tests as a family of lest cases 
derived from a common class (which in turn is derived from 
ihe TestCase class). In Ibis case, polymorphism allows test 
code to he reused in multiple tests, while allowing changes 
to specific operations and data when needed. 

Example. < >ur experience with the current framework lias 
shown that the time to port existing applications tests to the 
new API is minimal. Fig. 3 shows an example of how test 
code would look before and after being ported to the new 
test infrastructure. This example is an implementation of the 
client for an OMG CORBA program, which simply prints 
"hello, world." In this case, the phrase will he printed by Ihe 
sayjt method provided by the server code. The following 
descriptions point out some of the differences between the 
two source files. The numbers associated with the descrip- 
tions correspond to the numbers in Fig. 3. 

1. Fig. 3b shows poll ions of the test code with TestCase and 
TestEnvironment instrumentation. These classes are not in the 
code in Fig. 3a 



2. Fig. 3b includes the class declaration and method defini- 
tions of a HelloWorldTest class and a macro lo register Ihe defi- 
nition with the TestEnvironment The HelloWorldTest class is de- 
lived from the TestCase base class. Fig. 3a source has no 
HelloWorldTest class. 

3. The check_ev_and_ptr macro in the Fig. 3a source is greatly 
simplified in Ihe Fig. 3b source, thanks to the TestEnvironment's 
pnnt_exception ;uid is_nil methods. 

4 Fig. 3a has a main function, whereas in Fig. 3b. the main 
function is replaced by the HelloWorldTest constructor, de- 
structor, and run_body methods. This structure allows the 
OTF to inslaniiate and run the test code as needed. The 
constructor and destructor allow the test writer to separate 
out "execute once" code if desired. The run_body method may 
be executed more than once. 

o. Fig. 3a uses a file to store the object referenc e string 
created by the server. (Use of files is potentially difficult if 
Ute client and server are on different machines.) Fig. 3b uses 
the TestEnvironment's naming service to get the object refer- 
ence string. 

(5. In Fig. 3b argc and argv are not available as input parame- 
ters and musi be obtained from Ihe associated TestEnvironment. 

7. The int return parameter of the main function in Fig. 3a is 
replaced by the TestEnvironment::Result of the run_body method 
in Fig. 3b. The effeii is die same, to return Ihe success or 
failure of Ihe invocation. 

Next Steps. The following is a list of items under consider- 
ation for implementing Ihe rest of ihe design and adding 
more functionality to Ihe TestEnvironment and TestCase classes. 

• I'ser interface class. We are investigating Ihe possibility of 
encapsulating a graphical user interface I hat was designed 
for one of Ihe existing lest infrastructures. 

• Test controller class. Here again we are looking at encapsu- 
lating an existing test synchronization controller. 

• Memory leak detection. By adding this feature to the Test- 
Environment and TestCase classes, all lests will gel this func- 
tionality through inheritance. 

• Integration with run-lime debugging. This will improve 
tracing and fault isolation in a distributed, multithreaded 
environment. 

• Heterogeneous networks. The current object testing frame- 
work handles networks of HP-l'X* systems only. We need to 
expand the framework to handle other I'NTX systems as 
well as PC operating systems. 

Summary 

The object testing framework is based on using object- 
oriented technology to create a lesl infrastructure thai is 
based on a number of small, self-contained modules and 
then developing these modules in a way that allows the test- 
ing effort to proceed while the test infrastructure continues 
to evolve. Each step of the evolution results in a usable test 
infrastructure that keeps the lest effort online and provides 
critically needed support to product releases. 

In addition to our overall commitment to complete this proj- 
ect, and a desire to see it used in other organizations in HP 

involv ed in distributed object technology, we will continue 



80 December 1MB HewleB-Paekattl Journal 

© Copr. 1949-1998 Hewlett-Packard Co. 



// Standard C— headers 
•include <fslream h> 
•include <slring h> 

// Header lor CORBA Hello Worm obiecl 
•include < helloTypes hh : 
// Lis! of error messages 
eiiern char •msgsd 

7 Simple macro to check lor exceptions and valid pointers 
•define check ev_ and _ptr(ev. plr, errcodel 
0 First, check lor exception 
if I ev.exceptiontl II 

1 

cerr « msgslerrcode] « " Exception returned " « endl: \ 
return errcode: \ 

// Next, check for valid pointer 

i! CORBA ... nillptrlH 

cerr « msgslerrcode] « "Pointer is null." « endl. \ 
return errcode; \ 

— ® 



3 



int i 



mainlint argc. char *argvD) -"-(i) 
CORBA::Environment ev; 

// Open a file which contains the object reference string lor 
// the Hello interface Read the string. 

ifstream ll"hello_instance" 
ifdfll 

cerr « "Could not open V'hello instance^ lile " « endl; 
return 1; 



) 

char soref[1024l; 
f » soref; 

M(H){ 

cerr « "Could not read the stringilied object reference" 
« "from the \ 'hello instanceY" file." 
« endl; 
return 2; 

// Initialize the CORBA environement. gel pointer to the ORB 

CORBA ORB var orb = CORBA: ORB initlargc. argv, 

C0RBA::HP0RBid.evl; 

checkevand ptrlev, orb, 3); 

// Conven object reference string to object reference 

CORBA :0bjecl var hello objref 
= orb->slring to objectlsorel. evl; 
check ev and ptrlev, hello objref, 4), 



// Standard C— headers 
•include <fstream h> 
•include cstnng h> 

'/ Header for CORBA HelloWorld obiect 
•include <heltoTypes.hh> 

// Header for Test Case object 
•include "testcase.hh" 



-1 



fl List of error messages 
extern char "msgsQ 

0 Simple macro to check lor exceptions and valid pointers 
•define check ev and ptrtev. ptr, errcode 



// Check tor exception and valid pointer ~ 
< t 
ill te.print exceptionlevl II te.is_nillptr)l 

return TestEnvironmem Result 

(TestEnvironmenL;user_code + errcode). 

// Declaration of HelloWorldTest class 
class HelloWorldTest public TestCase 

i I 

public; 

HelloWorldTestll; 
-HelloWorldTestll; 
TeslEnvironment:;Result run body!), 



3 



private; 

C0RBA:;0RB ptr orb, 
HelloWorld ptr hello: 
char "message: 



J® 



r 



DECLARE_TESTCASE_FACTORY(HelloWorldTest); 

// Definition of HelloWorldTest constructor. 

// The following pieces of the test are considered set up. 

HelloWorldTest- HflloWorldTestn 

( 

CORBA Environment ev; 

// Get the object reference string for 

//the Hello interface Irom the test onvironment. 

string soref - te. get object stnngC'hello instance"); *~ 



// Initialize the CORBA environment, get pointer to ORB 
orb = CORBA ORB initlte.argc. te.argv. C0RBA::HP0RBid, ev): 
check ev and ptrtev, orb, 31, 

// Conven object reference string to object reference. 
C0RBA::0bject v,.r hello. objref 

= orb->string to objectlsorel. c strt I, evl; 
check ev and ptrlev. hello objref, 41; 

// Narrow the COBRA: Obiect obiect relercnce to a HelloWorld one. 
hello = HelloWorld:: narrowlhello objrel, evl, 
check ev and ptrtev, hello, 5); 
COBRA releaselhello objref); 



CORBA:strmg Ireelmessagel. 
CORBA::release(hello|; 
CORBA::releaselhello objrel): 
CORBA: release(orb); 

I 



CORBA::string Ireelmessagel. 
CORBA releaselhello); 
CORBA ;:release(orbl. 

) 



la) lb) 

Fig. 3. i;o Ttesi code before being ported to the objeci testing framework, do The same test after being potted 
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A New, Lightweight Fetal 
System 



Telemetry 



The HP Series 50 T fetal telemetry system combines both external and 
internal monitoring of the fetus in a small, lightweight transmitter that is 
easy and comfortable for the patient to carry It is useful for monitoring in 
labor, monitoring of high-risk patients, monitoring in transit, antepartum 
nonstress testing, and monitoring in the bath. 

by Andreas Boos, Michelle Houghton Jagger, Giinter W. Paret, and J urge n W. Hausmann 



Electronic fetal monitoring records fetal heart rate, uterine 
activity, and fetal movements onto a trace, allowing obstetri- 
cal clinicians to better assess fetal well-being and the ade- 
quacy of fetal oxygenation. 

In today's high-tech hospital environment it is easy to over- 
look the fact, that the majority of pregnant women who are 
admitted to the hospital to give birth are not sick, but are 
experiencing a natural event , the delivery of their babies. 
With this in mind, many hospitals worldwide are anxious to 
create a more friendly environment in their labor and deliv- 
ery departments by reducing the amount of technology at 
the patient's bedside. This reduction in technology can pres- 
ent a problem. Although patients want a more natural envi- 
ronment, the nursing staff still wants to be able to oversee 
fetal well-being during labor and delivery. There has to lie a 
balance between these two goals, and monitoring of the 
fetus via telemetry offers a solution. 

Telemetry monitoring of the fetus involves connecting a 
patient to a radio frequency transmitter, which she is able to 
cany (Fig. 1). This transmits the fetal information via L'lIF 
radio frequencies to a receiver connected to a fetal monitor. 
The monitor records the information as if the patient were 




Fig. 1. the HP Series 50 T fetal telemetry system transmitter is 
lightweight ;uid comfort able to wear. 



connected directly to it. The fetal monitor and receiver can 
be placed in a central location for the nursing stall to view 
the fetal information, and need not be in the patient's room, 
thereby reducing the perception of technology at her bedside. 

Fetal monitoring with telemetry has been available for the 
past ten years. Until now. these telemetry systems only al- 
lowed either external monitoring of the fetus such as ultra- 
sound detection of the fetal heart rate, or internal methods 
such as direct monitoring of the fetal heart rate by means of 
a scalp electrode. Very few systems offered both of these 
methods, and those that did were large and heavy for the 
patient to cany, and had a very low battery life. 

The Hewlett-Packard Series 50 T fetal telemetry system 
(IIP M131UA) is a new lightweight, space-saving telemetry 
system. It combines both external and internal monitoring 
of the fetus in a small, lightweight transmitter that is easy 
and comfortable for the patient to carry. Because the patient 
is not connected directly to the fetal monitor, a number of 
additional clinical applications can be addressed, including 
monitoring in labor, monitoring of high-risk patients, moni- 
toring in transit, antepartum nonstress testing, and monitor- 
ing in the bath. 

Monitoring in Labor. The technology used in the IIP Set les 
50 T ensures that the product can be used in the very earli- 
est stages of labor, before the membranes have nipt tired, 
right up lo and during die second stage of labor when the 
baby is being delivered. This means that the patient is free 
lo move around from the onset of labor, while a reliable, 
continuous fetal trace is available for overseeing fetal well- 
being. Allowing the paiienl to walk around can be beneficial 
for the patient, especially when the delivery is long, and can 
even help reduce the pain of her contractions. 

Monitoring of High-Risk Patients. When a high-risk patient has 
been admitted to the hospital for observation before the birth 
of her baby, it is often desirable to provide continuous moni- 
toring of the baby to ensure its well-being. However, this is 
not normally practical because it would mean connecting 
the patient to a fetal monitor and confining her to bed for 
long periods of time. I sing the HP Series 50 T fetal teleme- 
try system, the patient is free to walk around, and the nurs- 
ing staff has a constant overview of fetal well-being 
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Monitoring in Transit. Besides being compatible with all HP 
fetal monitors produced since 1982. the HP Series 50 T fetal 
telemetry system can use the standard transducers of the 
HP Series 50 family of fetal monitors. This is useful, for ex- 
ample, if an emergency occurs and the patient needs to be 
transported to the operating room for a Caesarean section. 
In certain countries it is a legal requirement to provide con- 
tinuous monitoring of the fetus from the time the patient 
leaves her room to the delivery of the baby. By disconnect- 
ing the transducers from the fetal monitor and connecting 
them to the transmitter of the HP Series 50 T. continuous, 
uninterrupted monitoring of die fetus is ensured. 

Antepartum Nonstress Testing. Nonstress testing is performed 
during the patient's regular visit to the clinic or hospital dur- 
ing her pregnancy. By allowing the patient to ambulate and 
record the fetal heart rate via ultrasound, nonstress testing 
can be performed without having to confute the patient to 
bed. thereby allowing her freedom of movement and the 
ability to socialize with the other patients. 

Monitoring in the Bath. Ii is becoming more common for a 
patient to be given a bath during labor to help reduce tiie 
pant of her contractions. Before the introduction of the HP 
Series 50 T fetal telemetry' system, there was no safe way of 
providing a continuous overview of fetal well-being while 
the patient relaxed in the bath. This meant vital information 
on the fetus could be missed. By using the HP Series 50 T in 
conjunction with lite standard watertight "blue" ultrasound 
and TOCOt transducers from the HP Series 50 family of 
fetal monitors, the nursing staff can be assured of a continu- 
ous recording of fetal information even when the patient 
decides to take a bath. 

Fetal Monitoring Measuring Methods and Principles 

The parameters measured iii fetal monitoring applications 

are fetal heart rate, fetal movements, and maternal labor 

activity. 

The fetal heart rate is continuously monitored on a beat-to- 
beai basis and recorded together with the maternal uterine 
aciiviiy and optionally the fetal movements on a fetal trace 

recorder. 

Tin-re are two established methods to measure lite fetal 
heart rate. One is to process the fetal ECU by using a fetid 
scalp electrode and measuring the time distance between 
two QRS complexes. This method is invasive and can only 
be used If the membranes have ruptured and the fetal scalp 
is accessible to attach the scalp E< 1 1 electrode This is true 
only for the last few hours before delivery. 

The second method of measuring felal heart rate is to calcu- 
late the heart rate from a Doppler-sltifted ultrasound signal 
by measuring the time distance between two signal com- 
plexes resulting front fetal In-art motion. A 1-MHz pulsed 
ultrasound signal is entitled towards lite feud heart and I he 
ultrasound waves are Doppler shifted by the moving parts of 
the heart and reflected. The reflected and iJoppler-shifled 
signal is received again and demodulated by a 1-MHz dork 

t TOCO is an abbreviation foi locogtapli oi tDCOdynaniumeler. an inslrumont lor maturing 
and returning the expulsive Inrce of uterine coniraclions in labor ll is usually writion in 
UPPBfCM loners like the abbreviations loi the ulnar lelal measuring molhods US = ultra- 
sound. ECG ■ eleclrocardiogram. IUP = intrauterine pressure 



signal. After filtering and amplification (by approximately 80 
to 106 dB). only the low-frequency Doppler-shified signals in 
the range of 100 to 500 Hz remain. These signals are fed to a 
loudspeaker to give the user audible feedback about the 
correct transducer positioning. Compared to the relatively 
simple algorithms needed for the heart-rate calculation from 
the ECG signal (the ECG signal is a well-defined, easy-to- 
recognize signal ) the algorithm for the ultrasound signal ts 
much more complex. The ultrasound Doppler signals con- 
tain a lot of different pulses as a result of reflections from 
different moving pans of the heart during one heart period. 
These pulses change their shapes and amplitudes depending 
on the angle between the ultrasound beam and the heart. 
Therefore, a simple peak-searching algorithm cannot accu- 
rately calculate the fetal heart rale from the ultrasound Dop- 
pler signal on a beat-to-beat basis, so a more complex algo- 
rithm using the autocorrelation function of the ultrasound 
signal is used. The autocorrelation function determines the 
similariiy between all the pulses of two consecutive heart- 
beats. The distance bet ween two points of highest similarity 
is then used to calculate the actual fetal heart rate. This 
method reaches a heart rate trace quality comparable to that 
of a trace derived from an ECG signal (the ECG signal is 
recognized as the "gold" standard for fetal heart rate moni- 
toring). The advantage of the ultrasound Doppler method is 
that it is a noninvasive method and can be used front the 
twentieth week of gestation up to delivery and no direct 
access to the fetus is necessary. 

Fetal movements can also be detected front the ulirasounil 
1 )oppler signal. The fetal movement signals differ front the 
Doppler heart rate signal in that they have a much higher 
amplitude and a lower frequency. The higher amplitude is 
because of the bigger size of the moving areas (e.g.. the fetal 
arms and legs) and the lower frequency is because of the 
lower velocity of the fetal movements compared with those 
of the fetal heart 

For measuring maternal labor aciiviiy (uterine activity), 

there are two established methods. The IUP (intrauterine 
pressure) method measures, as the name implies, the abso- 
lute pressure in the litems by inserting a pressure trans- 
ducer into the uterine cavity. This can be a precalibrated 
pressure sensor mounted in a catheter tip or a saline-solu- 
tion-filled catheter with a pressure sensor connected out- 
side. This method is invasive to the mother and can only be 
used If the membranes sue ruptured. The second method is 
an external noninvasive method (external T< ICO) which 
measures Ihe relative hardness of the abdominal wall and 
the underlying uterine muscle. This method provides rela- 
tive values and not absolute pressures like the ttJP catheter. 
The pressure sensor in both transducers is based on a resis- 
tive bridge with four pressure-sensitive elements. The bridge 
gives a high pressure sensitivity but needs differential ex- 
cilalion and a differential signal amplifier. 

Wireless Data Transmission 

There are many possibilities for wireless data transmission 
from one location to another. Each method has its individual 
advantages and disadvantages when analyzed for a specific 
application. We looked at infrared and radio frequency 
transmission and evaluated their advantages and disadvan- 
lages for lite fetal telemetry application. 
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Infrared light is widely used as a dala transmission method 
because of its simplicity and the fact thai no regulatory 
approvals are necessary. However, for the fetal telemetry 
application, its use is not possible because the transmitting 
range is very limited and secure data transmission is only 
possible on a line-of-sight basis. This means that the trans- 
mitter cannot be covered by clothes or a bed cover and the 
transmission range is limited to one room. These conditions 
cannot be guaranteed during labor and deliver.' because the 
patient can walk around and change her position freely, An- 
other disadvantage from the technical standpoint is the rela- 
tively high power consumption of an infrared system when 
used in a continuous transmission mode, which is necessary 
for continuous monitoring. 

Railio frequency transmission, another very widespread 
transmission method, overcomes most of the problems of 
infrared transmission when it is designed carefully and an 
appropriate frequency range is chosen. Frequencies below 
100 MHz will result in large antenna dimensions (the wave- 
length is 3 meters at 100 MHz) if high efficiency is needed 
(this is a strong requirement because of the battery-operated 
transmitter), t in the other hand, frequencies above 1 GHz 
result in a wavelength (<30 cm) at which antennas become 
more and more directional, signal generation requires more 
space and power, and it takes special processes to build 
printed circuit boards that can handle such high frequencies. 

A major disadv antage of radio frequency systems is that 
individual approval for each country is required and many 
different requirements and boundaries are given by all the 
national laws. These requirements must be fulfilled to obtain 
country approvals and should be covered by one design to 
avoid many special product options. Thus, the resulting de- 
sign must meet the most stringent specification of all the 
different national standards for each requirement. A positive 
aspect for Europe is the upcoming harmonization within the 
European Community ( EC) where one Standard will be used 
for all European community members. At the moment, Ger- 
many. Franc e, and Italy have converted this standard into 
national law (others will follow — a limit of two years is 
given for all countries to eomert this standard into national 
law). This means that for these countries only one standard 
is valid. 

The decision was made to use radio frequency data trans- 
mission. 

The following items and specifications have been set up for 
a telemetry design to meet all the requirements for world- 
wide use: 

The frequency must be configurable in the range of 406 MHz 
to 512 MHz. 

The radio frequency (RF) power must be adjustable in the 
range of 1 mW to < 10 m\V. 

The spurious emissions must be < — 30 dBm for frequencies 
< 1 GHz and < —30 dBm for frequencies > 1 GHz world- 
wide, and must be < —54 dBm in Europe iti the frequency 
ranges 42 to 68 MHz. 87 to 1 IS MHz, 162 to 230 MHz, and 
470 to 862 MHz. 

The RF bandwidth must be < 25 kHz worldwide and should 
be < 12.5 kHz for Japan (25 kHz would be acceptable but is 
not preferred ) 

The transmitter must be capable of sending a special identi- 
fication code after power-up for Japan. 



' The RF stability over temperature ( - 10 to +55°C) and hu- 
midity (5 to 95% R.H.) must be better than ± 3.5 kHz for the 
CS.A. and better than ±2.5 kHz for Europe and Asia. 

However, to design and build a radio frequency transmitter 
that meets all the above specifications requires extensive 
engineering manpower, testing, and design iterations. There- 
fore, we decided to reuse an existing RF transmitter and 
receiver for our fetal telemetry application. 

After examining all possibilities, we found a good candidate 
in the RF parts of the HP M 1400 adtdt ECG telemetry sys- 
tem. The RF pails of this telemetry system had all the ap- 
provals needed, and its highly modular design ( RF pails 
were strictly separated from the application-specific ele- 
ments) allowed us to pick up only those parts needed for 
our fetal application. The only modification needed was a 
small adaptation of the receiver's digital control software 
(which provides automatic frequency control — AFC — and 
the bilstream recovery of the digital protocol used to trans- 
fer the ECG waves). This software had to be modified to 
execute only the AFC function when used for the fetal appli- 
cation and not the bitstream recovery. It was even possible 
to modify the software so that it automatically switches to 
the correct application so that the same software can be 
used for the adult telemetry system and the Series 5(1 T. By 
reusing the adult RF parts, we dramatically reduced the en- 
gineering effort ;md only had to concentrate on the band- 
width specification (which is mainly determined by the mod- 
ulation) and the special Japanese ID code. 

The reused pails are the voltage-controlled crystal oscillator 
(VCXO) in the transmitter and as the local oscillator on the 
receiver side, the line amplifier as a receiver RF preampli- 
fier, the receiver module, and all antenna pails (antennas, 
combiners, splitters, power lees). 

Data Transmission and RF Modulation 

To get low adjacent channel emission, the — 6-dB RF band- 
width should not be wider than ± 8 kHz for a 25-kIlz chan- 
nel spacing. This gives a margin of ± 4 kHz for frequency 
drifts caused by temperature, humidity, and aging. 

The adult ECG telemetry system uses digital Gaussian mini- 
mum shift keying frequency modulation ( GMSK-FM) with a 
9600-bit/s dala rate. The resulting - 6-dB RF bandwidth is 
approximately ±8 kHz. 

Because the processing power needed to calculate the bean 
rate from the ultrasound Doppler signal is not available in 
the telemetry transmitter, the ultrasound Doppler signal is 
transmitted to a receiver, which feeds it to a coimected fetal 
monitor, which does all the signal processing. The telemetry 
system only acts as a wireless analog front end for the fetal 
monitor. The HP Series 50 fetal monitors sample the signals 
at a 1.6-kHz sample rate with 12-bit resolution. To transmit 
the ultrasound signal as a digital bitstream, the required data 
rate is 12 bits x 1600 samples/s = 19200 bits/s for the ultra- 
sound signal alone. Together with the uterine activity signal 
and the necessary framing and checksum overhead a mini- 
mum data rate of 22 kbils/s is required. This data rate does 
not include any redundancy needed for error correction. 

To fit into the 25-kHz channel bandwidth, this data rate must 
be compressed to 9600 bits/s. This requires highly sophisti- 
cated data compression circuitry. The data stream resulting 
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from a sampled ultrasound Doppler signal does not contain 
as much redundancy a* the ECG. winch does not change 
rapidly except for the short duration of the ECG QRS pulse. 
To fit into a 12.5-kHz channel spacing an additional data 
reduciion down to 4800 bits per second is needed. 

We decided to transmit the heart rate signal ( ultrasound 
Doppler or ECG ) with standard direct EM modulation. The 
uterine activity signal together with some status signals — 
battery status, nurse call function, serial number, and trans- 
ducer modes (ultrasound or ECG and external TOCO or 
II P) — are transmitted as a digital bitstream. This informa- 
tion is transmitted four times per second. Every data block 
is secured with an 8-bit checksum ( ) Ri |. A data block al- 
ways starts with the serial number of the transmitter. This 
serial number. which is the same for the transmitter and the 
corresponding receiver, is used by the receiver to synchro- 
nize itself with the datastream and to verify that the data is 
coming from its own transmitter. This ensures that signals 
from two different patients using the same RF frequency are 
not mixed. The overall data rate for the digital transmitted 
signals is 200 bits/s. This data stream is transmitted its a 
frequency shift keying t FSK) signal with a 1600-Hz signal for 
a logic 0 and a 2400-Ilz signal for a logic 1. This signal, 
added to the heart rate signal, frequency modulates the RF 
carrier. The amplitude of the composite signal determines 
the required RF bandwidth and can easily be adapted to 
meet the 12.5-kHz channel spacing requirements. 

RF Bandwidth 

The resulting RF bandwidth can be estimated as follows. 
The modulation signal is composed of two components: ( 1 ) 
the ultrasound Doppler signal or the ECG signal and (2) the 
FSK subcanier signal. The modulation spectrum is illus- 
trated in Fig. 2. 

The RF FM modulator has a sensitivity of 1.0 kllzA'. which is 
the specification of the reused RF oscillator from the adult 
F< '< ; telemetry system. The ultrasound signal has a band- 
width BW|f = BOO 11/. and an amplitude of 1.875 V,,. p which 
product's an RF carrier shift or 1.6 x 1.875 = 3.0 kHz. The 
corresponding modulation index is [i = frequency 
shift + modulating frequency = 3.0 kHz/500 Hz = (i. The ECG 
signal has a bandw idth BWjf = 100 Hz and a carrier shift of 
3 kHz. so the modulation index is |J = 3.0 kHz/100 Hz = 30. 

The FSK signal has as its highest frequency a 2.4-kHz sinu- 
soidal carrier Its amplitude produces an RF earner shift of 
1.5 kHz. The modulation index is P = 1.5 kHz/2.4 kHz = 
0.625. 
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Fig. 2. Modulation signal speeinim of the HI' Series ">u T fetal 
telemetry system iransinitter. 



For a modulation index less than one the RF bandwidth is 
approximately BW ri = 2BW| f . Only the Bessel functions of 
orders 0 and 1 have significant values (>0.01 ). so they repre- 
sent 99% of the RF energy, or in other words, outside this 
bandwidth the signal is 20 dB down from the maximum at 
center frequency. Thus, the - 20-dB RF bandwidth of the 
FSK carrier is 2 x 2.4 kHz = 4.8 kHz. For a bandwidth m here 
the signal is 40 dB down (99.99% of the RF energy is within 
this bandwidth ) the Bessel function of order 2 is also of in- 
terest and the - 40-dB RF bandwidth of the FSK carrier is 
4 x 2.4 kHz = 9.6 kHz. 

For a modulation index greater than one. the RF bandwidth 
is approximately BVV ri = 2((i+l)BW rf for a bandwidth where 
the signal is 20 dB down. For a bandwidth where the signal 
is 40 dB down this bandwidth doubles again: BWjf = 
4fJ*l)B% 

With a modulation index of 6. the ultrasound signal pro- 
duces an RF bandwidth of BW rf ( - 20-dB) =2(6+1 )500 Hz = 
14 x 500 Hz = 7 kHz or BW rf ( - 40-dB) = 4(6+1 )500 Hz = 
28 x 500 Hz = 14 kHz. 

With a modulation index of 30. the ECG signal has an RF 
bandwidth of BW rf ( - 20-dB) = 2(30+1)100 Hz = 6.2 kHz or 
BW rf ( - 40-dB) = 4(30+1)100 Hz = 12.4 kHz. 

Thus, the overall RF bandwidth is mainly determined by the 
ultrasound signal or the ECG signal and not by the FSK 
signal. 

The amplitude ratio between the heart rate signal and the 
FSK signal was chosen so that as the field strength at the 
receiver input goes down, the signal-to-noise ratio of the 
FSK signal decreases before the heart rate signal is affected. 
The receiver detects bit errors in the digital data stream and 
suppresses the heart rate output signals to the fetal monitor 
when errors OCCUr. Thus, the fetal monitor always shows 
either the correct heart rale values or no value, but never 
displays w rong values, which may lead to a misdiagnosis. 

Telemet ry Transmitter 

Fig. 3 shows the components of the HP Series 50 T fetal 
telemetry system. 

A high priority for the telemetry system design was to sup- 
port the same transducers as used by the HP Series 50 fetal 
monitors. Customers can use the transducers they normally 
use with their fetal monitors and can switch between stan- 
dard monitoring and telemetry monitoring simply by replug- 
ging the transducer connectors from One device to the other. 
Repositioning and reapplying the transducers Oil the patient 
are not necessary and the switch can be performed in a few 
seconds. This compatibility was no problem with the ultra- 
sound anil uterine activity transducers, but the fetal monitor 
ECG transducer required more detailed investigation to 
design circuitry to handle this transducer in the telemetry 
transmitter. 

The HP M1357A fetal ECG transducer is an active transducer 
in which the complete ECG preamplifier and its floating 
power supply are incorporated in the transducer legplate. 
Since the telemetry transmitter is battery powered, this 
floating, highly isolated preamplifier is overdesigned for 
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Fig. 3. Transmitter, transducers, and receiver Ofth/e HP Series 50 T 
fetal telemetry system. 

telemetry use. However, il is mandatory for use on a mains- 
powered fetal monitor, since patient safety requires all 
transducers that have direct contact with the patient via 
electrical conducting electrodes to he floating. 

The M 1357 A transducer requires a 10V peak-to-peak power 
supply signal with a frequency between 1(1(1 and 25(1 kHz. 
The ECG signal is transferred on the same wires by power 
load modulation, which means that the transducer varies its 
load on the driving circuit with the amplitude of the ECG 
signal. A circuit had to be designed that is capable of driving 
the HP M1357A transducer with a 10V peak-to-peak signal at 
250 kHz, sensing the load current, and operating from a 5V 
supply, A bridge driving circuit built with digital 74AC14 
inverters running at 250 kHz was found to he capable of 
delivering the required drive signal with enough power to 
supply the transducer. The load current is sensed by a 5-ohm 
resistor in the ground connection of the 71AC14 drivers. 
Fig. 4 shows the ECG transducer driver circuit. 

A major consideration when designing a telemetry system Is 
the power consumption of the transmitter. It runs from bat- 
teries and therefore a goal is to make the operating time as 
long as possible with one set of batteries. The low-power 
design of the HP Series 50 T transmitter extends the operat- 
ing time to more than 40 hours of continuous operating with 
ultrasound and external TOCO transducers connected. The 
power source is tliree AA alkaline cells. This is two to three 
times longer than competitiv e fetal telemetry systems. When 
used with NiCd batteries, the operating time is comparable 
with competitive systems, but the weight of the HP Series 
50 T transmitter is only half that of the lightest competitive 
transmitter. 

In addition to weight and operating time, another major as- 
pect of telemetry system design is transmitter size. To get 
the best use of the available volume, the IIP Series 50 T 
transmitter uses double-sided surface mount technology on 
the printed circuit boards. This reduces the board space by 
40 to 50% compared to single-sided technology and makes 
the HP Series 50 T transmitter the smallest and lightest of all 
competitive fetal telemetry transmitters. 



Fig. 5 Is a block diagram showing all major functions of the 
transmitter. A microcontroller is the heart of the transmitter. 
This seemed to be the best solution, considering all of the 
required features such as Japanese ID code transmission 
after power-up. nurse call function, serial number handling, 
analog hardware control depending upon the type of trans- 
ducer (ultrasound or fetal ECG, TOCO or IYP), battery status, 
and CRC calculation for every data frame. The microcontrol- 
ler gives more flexibility than an ASIC and the development 
time was shorter. With an appropriate controller it is pos- 
sible lo execute the fetal movement detection algorithm in 
the transmitter, thereby saving transmission capacity of the 
RF channel by transmitting only the movement detection bit 
instead of the fetal movement Doppler signal. 

Microcontroller Features 

We chose the Mitsubishi M37702-M2 10-bit controller. This 
controller has true Hi-bil processing power and many inte- 
grated peripheral Amotions, and is low in cost. It has 512 
bytes of internal HAM and 16K bytes of ROM. There are 
eight independent 16-bit timers. Five of these have their in- 
puts and outputs accessible on pins, can individually select 
the input clock from a predivider, and can run in several 
modes including timer, counter, pulse width modulator, one- 
shot, free-running, or triggered from input pins or software. 
The controller also has an independent watchdog timer, 
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Fig. 4. HP M1357A ECG transducer driver. 
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eighl channels of 8-bi( analog-to-digilal converters, and Iwo 
independent synchronous or asynchronous serial communi- 
cation channels. The package is a plastic quad llatpack with 
HO pins. The rich sel of integrated peripherals on I he control- 
ler chip allowed us to save a lot of hardware that would 
otherwise he needed outside the controller. 

The controller is available with 8-MHz, 10-MHz, or 25-MHz 
input clock speed. The processing power needed in the Hi' 
Series 50 T transmitter allows a reduction of the clock Ire 
quency to 2 MHz. When running with the 2-Mllz input clock 
and all peripheral functions active, the M37702 controller 
consumes only 1.5 inA with a 5V power supply. 

Three timers (one in timer mode, Iwo in one-shot mode) are 
used to produce the gating signals for the pulsed ullrasound 
Doppler channel. Fig. (i shows the resulting gating signals. 
With a sound velocity of 1501) m/S in human tissue, Ihe re- 
sulting ullrasound sensitivity over depth can he calculated. 
The minimum depth is determined hy the delay time be- 
tween the end of the ultrasound transmit pulse and the start 
of the receive gate pulse, which is t :1 in Fig. t>. With t;j = 32 
us. (I,,,,,, = (1500 x 10 8 x 32 x 10 " ,; )/2 = 2-1 nun. The maxi- 
mum depth is determined hy the lime helween the stall of 
Ihe transmit gate and the end of the receive gale, which is I- 
( t :( + l| = 224 us. The depth is then d m ;, x = ( 1500 x 10 :i 
•: 221 x LO" '')/2 = 1(18 mm. The factor of 2 in these calcula- 
tions results from Ihe fai l that Ihe ultrasound wave propa- 
gates first towards the reflecting object local ed at depth d 
and then back again lo (he transducer. 



Two timers are used to produce clock signals needed in Ihe 
ECO amplifier and the T< >('< ) transducer excitation circuitry. 
One timer is used to produce the 1(100/2-100-11/ FSK signal. 
One timer in court mode, together with an external first- 
order sigma-delta modulator (one comparator and One flip- 
flop), forms a 12-bil analog-io-digital convener for the uter- 
ine activity signal. 



Timer 2 
One-Shot 
Mode 



Timor 0 
Timer 
Mode 




Timer 1 
One-Shot 
Mode 






hH 


i 


» 


▼ 1 


r 



Frame Signal 



Transmit 
Gate Pulse 



t 

Receive 
Gale Pulse 



VI, 



Frame Signal 



J 



Transmit Gate 



Receive Gate 



Framing Rate I, = 3.2 kHz 
t, = t 3 = 32 |is 
l 2 = i , = 96 (is 



Fig. (i. i Itras 



I hippli-i' Killing 



© Copr. 1949-1998 Hewlett-Packard Co. 



Pocrmlifr liMlfi I Irwlpli-Parkaril .Inurnnl H7 



One serial communication channel in synchronous mode is 
used to control a serial EEPRO.M to store I he serial number, 
some calibration constants, the country option codes, and 
the power-up ID code for Japan. The second serial commu- 
nication port is used as a production and service port to 
read out internal signals, to program the EEPROM, and lo 
send messages during power-up if self-test failures are 
detected. 

The A-to-l) converters are used to monitor the battery volt- 
age, to measure the ultrasound Doppler or ECU signal am- 
plitude to control the signal gain, to measure the fetal move- 
ment signal amplitude, and to measure some lest voltages 
during the power-up self-tests. 

Uterine Activity Measurement Circuitry 

The uterine activ ity transducers are built with four pressure- 
sensitive resistors in a bridge configuration. This bridge con- 
figuration requires a differential excitation voltage and a 
differential sensing amplifier. The bridge resistors are in the 
range of 300 to 1000 ohms. The requirement of compatibility 
with standard fetal monitor transducers did not allow the 
use of a new transducer with a higher impedance to reduce 
the drive power. The I UP transducers are activ e and need a 
drive voltage of at least 5Vdc or 5Vac at > 1 kHz. The result- 
ing power consumption for the 300-ohm type is then P = 
V-/R = 25/300 = 83.3 mW, 

A circuit can be designed that reduces this power level to 
45 mW. The disadvantage is a sensitivity reduction by 6 dB, 



that is, the sensitivity is halved. This can be compensated by 
doubling the gain of the sensing amplifier. A 5Vac excitation 
at 1.6 kHz ( half the repetition frequency of the pulsed ultra- 
sound Doppler to avoid interference between the TOCO 
drive circuitry and the ultrasound demodulator) was chosen 
instead of a simpler dc drive circuit because low-power op- 
erational amplifiers running on "A" or less with high dc preci- 
sion have not been available for reasonable prices. The labor 
activity signal, which is a signal with a bandwidth from dc to 
< 2 Hz, is obtained by a synchronous demodulator running 
at 1.6 kHz and a low-pass filter. By using ac excitation, the 
sense amplifier can be built with simple and inexpensive 
TL0(i2A amplifiers. 

Fig. 7 shows the implementation of this circuitry. The TOCO 
excitation applies power ( +5V and ground ) for the first half 
of a 1000-IIz square wave (50% duty cycle ). During the sec- 
ond half, the excitation drive is switched off. This halves the 
power consiunption of die TOCO transducer resistive bridge. 
A differential amplifier senses the bridge signal, amplifies it. 
and converts the differential signal into a single-ended sig- 
nal. The input capacitors settle to the bridge output voltage 
during the active drive phase of the excitation driver and 
discharge to a middle value during the nondriving phase 
through the bridge resistors, In this way. the sensing ampli- 
fier input picks up a 1000-Hz signal with half the amplitude 
compared to a full-bridge excitation driver. The signals are 
illustrated in Fig. 8. 
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Fig. 8. TOCO signal waveforms, (a) Excitation signal, (h) Sense 
amplifier differential Input (low bridge differential signal), 
(c) Sense amplifier differential input (liigh bridge differenluil 
signal), (d) Sense amplifier differential input with true bridge 
excitation. 

Power Supply 

An essential part of a battery powered handheld device is 
the power supply. The fetal lelemelrv transmitter is designed 
to run with three AA-size alkaline batteries or rechargeable 
NiCd accumulators. The new and more environmental 
friendly NiMH accumulators are also supported. 

The input voltage is from 2.5 to I S volts. The power supply 

must provide the following output voltages: 

+-5V. Main supply voltage for all digital and mosl analog 

circuits 

- J "V Virtual ground for 5V single-supply analog circuits 
+.S.5V. Supply for some operational amplifiers and the ultra- 
sound receiver preamplifier 

—3.5V. Negative supply for a few operational amplifiers to 
increase I he signal dynamic range. 

The power supply is a swilched-mode type delivering a 
stable ( ± 1%) +5V output from the batteries. .Ml other volt- 
ages, which need only a few millianiperes. are built with 
charge pumps or simple buffered voltage dividers. The 
switched-mode power supply runs at 250 kHz in a pulse 
width modulation mode. The 250-kIIz switching frequency 
has the advantage that only small inductors are needed. Part 
of the power supply is also the main crystal-controlled clock 
oscillator running at -I MHz. All other clock signals are de- 
rived from this master clock, The oscillator and the power 
supply are designed to start with input voltages as low as 
2.0V. The efficiency of the power supply varies between 70% 
for low (2.5V) input voltages and 82% with a 4.5V input. 
Fig. !l is a diagram of the transmitter power supply 



Japanese ID Code 

Japanese radio frequency laws require that a special identifi- 
cation code be transmitted every time the transmitter is 
switched on. The code bitstream is modulated on a subcar- 
rier with a speed of 1200 or 2400 bits/s or is direct FSK or 
GMSK modulation of the radio frequency carrier signal at 
1200. 2400. or 4800 bits's for FSK and 2000. 4000. or 8000 
bits/s for OMSK modulation. The bit rate must be accurate 
within a tolerance of ± 200 ppm. The code is composed of 
(1) > 100 bits of alternating ones and zeros. (2) a 31 -bit max- 
imum-length pseudorandom noise code sequence. (3) 51 ID 
code bits (provided by the regulatory agency, this code is 
unique for every transmitter and contains information about 
the device manufacturer and the product, and a unique se- 
rial number that has nothing to do with the normal product 
serial number), (4) a 12-bit checksum calculated from the 51 
code bits by a special polynominal division. 

In the HP Series 50 T transmitter, this code is stored in the 
EEPROM during the production final test. During a pow- 
er-up sequence, this code is read by the transmitter micro- 
controller and transmitted as a 1200-bit/s FSK signal before 
starting normal transmission. The code in the EEPROM is 
also secured by a checksum. If this checksum is corrupted, 
the transmitter will not start normal transmission as re- 
quired by the regulatory agency. This feature is only active 
for Japanese options (also stored in the EEPROM) and is 
ignored for all other countries. 

Modulation Circuits 

The modulation circuits have a twofold responsibility. One is 
controlling the RF bandwidth with its amplitude and fre- 
quency characteristics and thus maintaining conformity 
With RF regulatory requirements. The other is making the 
best use of the available RF bandwidth to get the best pos- 
sible signal-lo-noise ratio for the transmitted signals. 

Fig. 10 shows the modulation circuits. The circuitry consists 
of three suhcircuils: a programmable-gain amplifier, a lim- 
iter, and a low-pass FSK shaping filter. 

The programmable-gain amplifier adjusts the heart rale sig- 
nal amplitude to a value that corresponds to 1)0% of the max- 
imum allowable RF bandwidth. The margin of 40% is to ac- 
commodate the often rapidly changing signal amplitude, 
especially for the ultrasound Doppler signal. The gain of the 
amplifier is controlled by a regulator algorithm implemented 
in the M37702 controller. The current signal amplitude is 
measured with one of the integrated A-to-D convener chan- 
nels, and from this value an appropriate gain is calculated 
for the programmable-gain amplifier, This amplifier consists 
of an operational amplifier with an 8-hit multiplying D-to-A 
converter in its feedback path. So as not to change the gain 
too much during one heart period (which could lead to a 
wrong heart rate calculation for the affected beat ), the new 
gain value is adjusted linearly over two seconds. Therefore, 
the 40% margin is provided so that the amplifier docs not 
overdrive the signal too often. 

The limitei circuit following the programmable-gain ampli- 
fier clips the signal to well-defined limits in the case of a 
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suddenly increasing input signal to the programmable-gain 
amplifier. The low-pass filter, which also acts as a bandpass 
filter and a summing amplifier for the square wave FSK sig- 
nal, removes the overtones resulting from the clipping and 
thereby ensures that the modulation has a well-defined RF 
bandwidth. 

Telemetry Receiver 

The recovery of the digital bitstream in the FSK signal is the 
main task of the receiver. The FSK signal is extracted from 



the composite signal (FSK and heart rate signal) by an analog 
bandpass filter with 1400-IIz and 2(500-Hz comer frequencies. 
The recovered sinusoidal FSK signal is converted into a 
square wave by a comparator. All subsequent recovery tasks 
arc implemented in a Mitsubishi M37702-M2 microcontroller 
(the same type as used in the transmitter). 

Digital data recovery can be divided into two main tasks: 
FSK signal demodulation (recovering the single bits from 
the Kit 10/24 00-Hz input signal) and synchronization with the 
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Fig. 10. Transmitter modulation circuits. 
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transmitted data frames. Fig. 11 shows the FSK signal de- 
modulation sc heme, which is completely implemented in the 
microcontroller. 

The pulse period measuring circuitry is composed of two 
microcontroller timers. The first tinier is configured as a 
retriggerable 250-us one-shot and the second is configured 
for pulse period measurement. The incoming FSK square 
wave signal first triggers the one-shot, which suppresses 
very short periods between two positive edges in the incom- 
ing signal and triggers the pulse period measurement tinier. 
The timer generates an interrupt whenever a new pulse 
period measurement is complete. For noise rejection, the 
period values are low-pass filtered and all period values that 
are outside the limits for a UiOO-Hz or 24<)0-Hz input fre- 
quency are rejec ted. This greatly improves the signal recov- 
ery for noisy input signals. 

The integrate and dump block sums all of the incoming 
period values. After five milliseconds, which is one bit time, 
the sum is reset by a dump signal delivered by the bit clock 
recovery digital phase-locked loop. Before reset, a compara- 
tor decides if the received bit was a logic one or a zero. 

The phase-locked loop block recovers the bit clock from the 
incoming data stream and generates the sample and dump 
signals, which are phase synchronized with the incoming 
data clock. Only input sequences consisting of one or two 
equal bits | hit patterns U10, 101, 01 10, and 1001) are used for 
the phase tracking. The one- or two-bit detector produces a 
reference signal whenever one of the four bit patterns is 
detected in the incoming bilstream. The detector measures 
the time between changes in the incoming period signals 
and checks lo see if this lime falls within the liniils fur one 
or two bit times (-1 to ii ms for one bit and 9 to 1 1 ms for two 
bits). 

To extract the individual frames front I In- recovered bit- 
stream, the structure shown Fig. 12 is used. The recovered 
bits are shifted into a ">0-bil-decp serial in. parallel mil shift 
register, which is the length of one frame. A complete frame 
can be stored in this shifl register and all of its bits analyzed 
;ii mice. 

The header search algorithm looks for a valid header pattern 
in bit positions -"ill to 4«S. The header pattern is derived from 
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Fig. 12. Data stream recovery in the HP Series oil T fetal telemetry 
system receiver. 

the system serial number (transiniiter and receiver have the 
same serial number stored in their EEPROMS). Bits 49 and 
•50 are used to identify whether a frame has been scrambled 
before transmission. The scrambling is done if the original 
frame did not contain enough single or double bit patterns 
for the clock recovery phase-locked loop. The scrambling is 
done by inverting every second bit in the frame. 

If a valid header (original or scrambled as indicated by the 
scrambling identification hits) is found, the complete frame 
is checked for a good ( 'R( ' pattern by the CR( ' calculation 
block. If the C'RC is < >K. the complete frame is deassembled 
into the original information and saved, the header search is 
disabled for a complete frame, and a synchronization done 
flag is set . 

If the ERG is not OK for more than two frames, the header 
search is enabled again and the synchronization losl Hag is 
set. The time since the last correct C'R< ' is measured by a bit 
counter. If more than 100 bits are receiv ed without B correct 

checksum, the synchronization process is restarted. 
Test Strategy 

To ensure maximum reliability and safety, extensive self- 
lesls are executed each lime the transmitter and receiver 
are powered up. Not only are the easy-to-lesl digital parts 
checked, but also most of the analog hardware. This is done 
by generating artificial signals, feeding them into the differ- 
ent analog signal paths and measuring I he response of each 
path. All these tasks are performed by the onboard M37702 
controllers in the transmitter and the receiver. The results 
obtained are checked against limits. If any deviation is de- 
tected, a clear failure message is sent out over the integrated 
service port (RS-2.12 line) to assist in troubleshooting, and 
the transmit te r or receiver tries to restart. This ensures that 
a faulty device does not go into norma] operation and that 
no incorrect tlata is transmitted or displayed by the attached 
fetal monitor. Tests have shown that about 80% of all pai l 
Shorts or opens are detectable in the analog processing 
pails. This is a very high number for power-up analog lesls. 
Achieving such a high error detect rate was only possible 
through the use of a powerful microcontroller. The soil ware 
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for self-test and service support is about 40% of the com- 
plete software package. 

Production testing of the transmitter and receiver is divided 
into two parts: single component or board testing before 
final assembly and final lesi of the completely assembled 
device. 

The loaded boards are tested by an automatic test system. 
Connection to the circuitry on a board is made by a needle 
bed adapter which allows stimulation and measurement of 
every net and every component on the board. The goal of 
this test is to verify that all components are loaded correctly 
and have the right values. If a component fails, the tester 
reports the component, its location and the detected failure. 
For surface mount boards, most failures are bad solder 
joints and shorts between pins. To test complex parts like 
RAMs, A-to-D converters, microprocessors, and microcon- 
trollers, a library model of the part describing its behavior 
on predefined stimuli is required. To check for good solder 
joints, a model that toggles every pin of a component as 
input or output is sufficient. Unfortunately, such a model 
was not available for the M37702 controller, which Ls an 
80-pin device in a quad flat package. To test this component, 
we implemented special software in the controller itself, 
which can be activated by the test system by pulling a pin to 
+5V. This pin is checked by the software during the pow- 
er-up cycle and the special test software is entered if the pin 
is pulled high. The special software mirrors the input pins to 
the output pins. The test system only has to apply a test pat- 
tern to the inputs and then check for this pattern on the cor- 
responding output nets. 

The HP Series 50 T fetal telemetry system uses the same 
final lest equipment as the Series 50 fetal monitors. Most of 
the final specification tests are similar or identical to the 
Series 50 fetal monitor tests. Therefore, we implemented a 
production and service interface identical to those of the 
fetal monitors. Only a few tests had to be added to cover the 
telemetry-specific specifications. The lest itself is highly 
automated and controlled by a workstation computer. This 
computer controls the measurement equipment , performs 
the measurements, prints the results and stores die results 
in a database. This allows continuous production process 
control by calculating the C'pk value (a value that describes 
the production process capabilities) for each test specifica- 
tion to check the stability of all production processes. This 
also makes it possible to detect test result drift resulting 
from pail changes before a lest result completely fails the 
specification. This process control procedure is supported 
by ISO 9001 and EN 46001 certification rules, and it really 
increases the product quality and stability, which the cus- 
tomer can directly see. 

Support Strategy 

The IIP Series 50 T fetal telemetry system can be used as a 
standalone unit with a local antenna, or the receiver can be 
connected to an existing antenna system. When connected 
to an antenna system the coverage area is increased. The 
design of antenna systems and the connection of the Series 
50 T to an antenna system is the responsibility of HP cus- 
tomer engineers. For standalone systems the system is de- 
signed to be installed by the customer (plug-and-play ). 



The acceptance tests needed to ensure proper functionality 
are built into the firmware and can easily be performed by 
the customer. In case of any problems the customer can call 
the IIP medical response center. The response center engi- 
neer has the ability to give troubleshooting instructions and 
find the defective assembly. 

All of the low-frequency assemblies can be replaced onsite 
or on die repair bench. The RF assemblies 1400 to 500 MHz) 
can only be repaired on the repair bench because high-preci- 
sion RF instruments are needed to do RF troubleshooting. 
Special service software is available to assist in trouble- 
shooting. This software provides check data for transmission, 
monitors field strength, and transfers serial numbers when 
needed for repair. 

The support features were implemented with minimal effort 
because the support requirements were discussed with field 
support personnel and their inputs were considered by R&D 
in the design phase. 

Error Detection and Display 

The HP Series 50 T is designed to show any software mal- 
function through the use of red LEDs in a certain sequence. 
Hardware failures can be troubleshot by the response center 
by telephone by following certain procedures and noting the 
results. 

The processor boards of both the transmitter and the re- 
ceiver run self-tesl routines after power-on to test hardware 
functionality and software integrity. After power-on. the re- 
ceiver switches on all LEDs for one second to test them, and 
then returns to normal operation. If the power-on test fails, 
all LEDs stay lit. indicating an error condition. After 
power-on. the transmitter switches on a red LED hidden 
behind the positive connection on the middle battery inside 
the battery compartment This LED stays on for three sec- 
onds, and if everything works it is switched off. If there are 
any errors this LED stays lit. All this visible information is 
very helpful to the response center engineer checking for 
system malfunctions via telephone with the customer. A 
defective section can be located in a very short time with 
high accuracy, helping to ensure low cost of ownership for 
the user. 

Troubleshooting Tools 

Troubleshooting tools are built into the system to provide an 
internal error log. reporting on settings and failures. This log 
can be accessed by software running on a standard PC" via 
an RS-232 connection to the receiver or transmitter. The 
software log is detailed and includes an interpretation of 
each error message, so no manual is required. 

Should a fetal telemetry system need repair, the software to 
test the internal functions and do simple troubleshooting is 
built into the unit. On the repair bench, during onsite repair, 
or during biomedical testing, it is only necessary to © mneet 
the system to a standard PC and start the service software 
to have the built-in troubleshooting help available. The con- 
nection between the PC and the transmitter or receiver is a 
3rwire RS-232 interface. All transmitter and receiver re- 
sponses can be tested. For hardware replacements, such as 
the transmitter or receiver CPU board, the serial number of 
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the system needs to be written to the new board using the 
service software. To avoid typing errors, we decided to read 
the serial number from the nundefective unit (transmitter or 
receiver) and transfer tt to the new unit ( receiver or trans- 
mitter), in tile case of intermittent failures the IV running 
the service software can be connected to the system and the 
PC can collect the error log overnight. The service software 
is designed to be tolallv self-descriliing with all reported 
messages interpreted, thereby avoiding error codes, which 
require error tables to find the problem description. The 
main screen of the service software shows the following 
information: 

***** M1310A Service Software Rev.AOl.O * * * * * 





M A I N ME N I 


* 


* 


- Program S/N to Transmitter 
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* 


- Program S/N to Receiver 
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- Power On Selftesl 
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* Show last errors/warnings 
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- Check Transmitter 
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- Check Receiver 
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- Read SerNum and Revisions 
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* 


- Reset Serial Number 
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- Read country information 
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- EXIT 
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* 
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* * * * 


******************** 


* * * * 


* 


Select with <up>. <down>, <enter> 
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* * * * 


******************** 


* * * * 



The following represents the first screen to program the 
Serial number to the transmitter: 
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******************* 
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Select with <up>, <down>, <enter> 
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* * 


****** 


******************* 


* 



The user is guided step-by-step through the program: no 
manual is needed. 

Installation Acceptance 

After installing the fetal telemetry system the performance 
of the system should be tested. The installation acceptance 
test is built-in. Overall transmission between the transmitter, 
receiver, and fetal monitor is checked by creating a synthetic 
signal. This is a simple operation that can be done by the 
customer. 

The synthetic signal for the acceptance test is generated in 
the transnutter and shows a test pattern on die fetal moni- 
tor. One heart rate transducer and one TOCO transducer can 
be connected to the transmitter, and the acceptance test 
give* the appropriate output for the transducers connected. 
The acceptance test is started by pushing and holding down 
the nurse call button while switching on the transmitter 
power. The lest runs as long as the nurse call button is 
pushed! "it flte fetal monitor a heart rate is measured and a 
TOCO triangular waveform shows the proper functioning of 
the overall system. This acceptance test verifies the overall 
transmission from the transmitter to the receiver via radio 
frequencies and the transmission from the receiver to the 
fetal monitor via cable connection. If all the signals are 
transmitted as expected the fetal telemetry finality is 
acceptable. 

The acceptance test is designed to avoid any need for exter- 
nal test tools or measurement equipment Because it is easy 

to perform and no external equipment is needed, this test 

helps save installation costs and reduces cost of ownership. 
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Zero Bias Detector Diodes for the 
RF/ID Market 

Hewlett-Packard's newest silicon detector diodes were developed to meet 
the requirements for receiver service in radio frequency identification 
tags. These requirements include portability, small size, long life, and low 
cost. 

by Rolando R. Buted 



Tracking of products and sen ices is critical in today's highly 
competitive and rapidly growing world of manufacturing 
and serv ice industries. To succeed in these industries, accu- 
rate and timely information is required. 

Two widely used tracking methods are bar code readers and 
magnetic Stripe. Although commonplace, they are both lim- 
ited in their range and their operating environment. For ex- 
ample, bar codes require a direct line of sight within a few 
inches and a relatively clean and benign environment to 
operate reliably. 

In contrast, a radio frequency identification ( RF/ID) system 
uses radio signals to communicate. Line of sight is not 
needed and the system can operate in hostile environments 
characterized by water, oil. paint, and dirt. Il can even be 
used for communication through cement, glass, wood, or 
other nonmetallie materials. These wireless systems are 
being successfully used to identify and track cattle, house- 
hold pets, cars passing through toll booths, supermarket 
carts, railroad cars, and personnel entering and leaving 
secure facilities. 

An RF/ID system is composed of two components: a reader 
(interrogator), which contains both transmitter/receiver and 
decoder/control modules, arid a tag (transponder), which 
typically contains an antenna and a receiver circuit. Since a 
system normally has only a few interrogators but many tags, 
the most severe design constraints are on the tag. These 
constraints include portability, small size, long life, and low 
cost. Hewlett-Packard's newest silicon detector diodes 
(IIS.\lS-285x) were developed to address these constraints. 

RF/ID Technology 

RF/TD tags can be active or passive. Active tags have an on- 
board power source (a battery) so that less power is needed 
from the reader, and usually have a longer read range. Mow- 
ever, they have a limited life span and are generally more 
expensive to manufacture. 

Passiv e tags do not need a separate externa] power source. 
They derive their operating power from the energy sent by 
the interrogator. Passive tags are lighter and cheaper than 
active tags and have Virtually unlimited lifetime. Some pas- 
sive tags contain a battery to maintain internal memory in- 
formation in read/write applications, The trade-off is that 
passive tags have a shorter read range than active tags and 



require a much higher-powered reader to supply the energy- 
needed to operate them. 

RF/ID tags can be read-only or read/write. Read-only tags, as 
the name implies, can only be read, but can be read millions 
of times. Read/write tags allow die data stored in them to be 
altered in addition to being read. 

Whether the tag is passive or active, read-only or read/write, 
it requires a receiver circuit. Receiver circuits can be of two 
types: superheterodyne or crystal video (Fig. 1 ). Because 
the superheterodyne receiver contains RF and low noise 
amplifiers, its detection sensitivity is typically -150 dBm. 
The crystal video receiver, on the other hand, is limited to 
only about -55 dBm. However, it is simpler and much 
cheaper than the superheterodyne receiver, so the RF/ID 
industry has adopted it for use in tags. The superheterodyne 
receiver is used in interrogators. 

The crystal video receiver of Fig. 1 can take different forms, 
depending on the application. Four common configurations 
are shown in Fig. 2. The single-diode circuits offer simplicity 
and low cost, whereas the voltage doubler circuits provide a 
higher output for a given input. Each type can be designed 
with conventional n-type Schottky diodes or zero biased 
p-type Schottky diodes. If n-type diodes are used, an external 
dc bias source is needed for detection operation at low input 
power levels (<] mW) because of the low saturation cur- 
rent. The p-type zero bias diode does not need a bias source 
because it has a relatively high saturation current. In addi- 
tion, it offers the lowest possible cost. size, and complexity. 



Antenna Antenna I 



Schottky 




Fig. 1. (a) Superheterodyne receiver. In RF/ID applications, this 
receiver type is used mainly in interrogators, (h) Crystal vidc i i 
receiver. This type is used in RF/ID tags. 
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Backscatter RF/ID Systems 



Automatic vehioe identification IAVII is one aspect of intelligent yebicie-highwav 
systems IIVHSI It is a good example of the use of RF/IQ technology m a practical 
application Poi e«ampie. RHD systems ate be<ng integrated into electronic toil 
collection at bndges so that tolls can be deducted from an account by using infor- 
mation stored m a tag mounted In the vehicle's windshield 

One of the key requirements of these systems rs that the stationary reader 
(interrogator) be aoie to discriminate between individual tags passing the ton 
booth without interference from oihei tags or other transmitters that may Oe 
operating at the same frequency Backscatter modulation technology is one 
method that can be used for such an application 

A block Diagram of a typical transponder (tag) for backscatter technology is shown 
in Fig 1 The interrogator Ireaden sends a modulated RF signal that is received by 
the tag The Schottky diode detector demodulates the signal and transfers the 
data to the digital circuits of the tag The radar cross section of the tag is changed 
Dy a frequency shift keying encoder and switch driver so that the reflected Iback- 
scatteredl signal from the tag is modulated and ultimately detected By the reader's 
receiver antenna Thus, communication between the tag and reader is established 

By using backscatter technology, interference from nearby transmitters can be 
avoided, since the reader controls the frequency of operation and can shift it if 
nearby transmitters are operating at the same frequency Also, the reflected signal 
strength from the tag is proportional to the incident interrogator signal, so tags 
outside the incident beam focus area will reflect a weaker signal that the reader 
antenna can reject 



Such a backscatter tag can have read/wnte capabilities that allow fteiuble digital 
formats It can also contain various tag information that can be used in other IVHS 
applications A specific minimum held strength is required to put the Schottky 
detector diode mto forward bias so that the tag does not backscatter until the 
nterrogator signal and message data are recei»ea thus mimmmng the power 
requirements of the tag 



BKkscJtnr 
Mismatch 




Rg. I. Typical transponder block diagram for backscatter RF/ID technology 



and usually exhibits the lowest flicker noise. It is therefore 
the diode of choice for RF tan applications. 

The performance of an RF/ID system is directly related to 
the frequency range in which it is used. The higher the fre- 
quency, die faster Hie data transfer rale and the longer the 
read/write range. The lag's riipluir IfftndOtO is more focused 
at higher frei|uency. Melals absorb low-frequency signals 
more than high-frequency signals, whereas obscuring mate- 
rials such as din and grease absorb high-frequency signals 




DC Bias 



r — DC Bias 




lol (b) 

Fig. 2. Different crystal video receiver nuifigiiratirins, (a) Zero 
iii.-is Si hottky diodes, (b) Conventional n-type Schottky diodes. 



more than low frequency signals. Most RF/ID systems oper- 
ate in three basic frequency ranges. The high-frequency 
ranges include 850 to 950 MHz and 2.4 to 2.5 GHz. The low 
frequency range is 10(1 to 500 kHz. close to the range of AM 
radio stations. Some applications, such as auto loll collec- 
tion, also use 5.8(i GHz and 10.5 GHz. 

Device Theon 

A Schottky diode is simply a melal layer deposited on a 
semiconductor such as silicon. To improve its performance 
and reliability, it can be passivated with silicon dioxide or 
silicon nitride or both. 

The equivalent circuit of a Scholtky diode is shown in Fig. 3, 
along with package parasitic elements. In the diode chip, R s 
represents the series resistance of the diode, which includes 
bulk and contact resist ances. Junction capacitance Cj is 
determined to a Brat-order approximation by the metal used, 
the silicon doping, and the active area. Rj is the junction 
resistance, often called the video resistance R v . and is a 




Fig. 3. Tins in. nM de» tBm ''ii 9 WQH packaged Schottky rtlorlr 
In 111 (ill/, Willi Rood accural ,\ 
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function of the total current flowing through the device LoVi 
Cj, Rv, and R s are desired for an efficient detector diode. 

The lolal current I flowing through a Schottkv diode is given 
l.y: 

I = IsfexpfV^nV,! - l| . 

where I s is the diode saturation current, V'|, is the voltage 
across the Schollky liarrier, n is the ideality factor, and V| is 
the thermal voltage. The voltage across the Schottky harrier 
is equal to an applied voltage V ; , minus any voltage drop 
across the series resistance R*. that is. V|, = V a - IR S . Ai low 
bias levels. R s can he neglected, so V|, ~ V i( . 

Tin' video resistance is R v = dvydl, so for small U, 

R v = nV,/l. 

For the zero bias condition, v., ^ i). ai room temperature 

wilh n = 1. the video resistance simplifies lo: 

R v = 0.026 /l s . 

By increasing U, the video resistance of the diode al zero 
bias is minimized. I s is increased by proper selection of I he 
metal type and the semiconductor doping. For silicon, p-lype 
generally gives a higher I s than n-type. However, p-type sili- 
con has higher R s than n-lype silicon wilh Ihe same doping. 
Increasing Ihe silicon doping to lower the R s also increases 
Cj, which degrades the detector performance. N-type 
Schottky diodes are seen in mixer applications because of 
Ihe lower R s and Ihe fact that R v can be kept low by using 
high local oscillator drive levels. 

Design Goals 

An important performance characteristic used lo describe 
\ideo detector diodes is voltage sensitivity, or 7. This param- 
eter specifies the slope of the curve of output video vollage 
versus input signal power, that is: 

Vo = yP m - 

Neglecting parasitic and reflection losses, voltage sensitivity 
can be defined as: 

v = iV('"'i/''V) . 

where |3 is Ihe current sensitivity and has a theoretical 
value 1 of 20 AAV Using the diode equation (with ideality 
factor n = 1 ): 

dl/flV = 1/0.026 . 
Therefore. 

Y = 0.52/1 . 
For zero hias detectors. 7 = II. "2 l„. 

This simple analysis of a perfect detector gives a poor 
approximation to the actual data on existing diodes. To 
bring the analysis closerto reality, effects of diode junction 
capacitance, diode series resistance, load resistance, and 
reflection loss must be considered. 

Diode Capacitance and Resistance. In most cases, the junction 
impedance associated with H N and ("j is much greater than 



Rs, especially al low frequencies. However, al high frequen- 
cies, the junction impedance Is reduced so that the RF 
power dissipated in R > is comparable to thai of the junction 
Incorporating the effects of Ihe diode capacitance and resis- 
tance on the current sensitivity,- the voltage sensitivity for 
the zero bias diode becomes: 

7, = 0.52/(l s (l + oA-fRsiiv)) , 

where o> = 2rcf. Cj is junction capacitance, l s is diode satura- 
tion current. R s is Ihe series resistance, and R v is the junction 
resistance. 

Load Resistance. The diode resistance R, al zero bias is usu- 
ally not small compared lo the load resistance R|,. If Ihe 
diode is considered as a voltage source with impedance R v 
feeding Ihe load resistance R|.. the vollage sensitivity will be 
reduced by the factor R|./(Rl + R\-)- (,r: 

72 = YllMRv + R|.l) • 

For example, a typical load resistance is 100 kil. If R v is 
5 kii then 

iS = 7 1(0-952) . 

Reflection Loss. Further reduction in voltage sensitivity i s 
caused by reflection losses in Ihe matching circuit in which 
Ihe diode i> used In Fig. ■'!. Ihe package capacitance ' \, t _ 
and package inductance can be used to determine the 
packaged diode reflection coefficienl. If this diode termi- 
nal es a 50S2 system, ihe reflection coefficienl p is: 

p = (Z D - 50)/(Z n + 50) , 

where Zp is a function of frequency and Ihe package parasit- 
ics. If there is no matching network, the voltage sensitivity 
can be calculated as: 

Y:t = 72<1 - P 2 ) • 

The chip, package, and circuit parameters all combine to 
define an optimum vollage sensitivity for a given applica- 
tion. Our design goal was to develop a diode 10 operale in 
Ihe frequency range used in RF/1D tags, ('sing the vollage 
sensitivity analysis described above, we hoped lo produce 
an optimum, low-cost, manufacturable pan in the shortest 
time possible. 

Implementation and Fabrication 

Hewlett-Packard's preeminent zero bias detector diode 
(HS('H--')48(j ) already provides excellent detection sensitiv- 
ity in an axially leaded glass package, particularly at high 
frequencies. To meet our design goals, the project team 
dei ided lo leverage Ihe I1SI II :.J48(i technology. 

We chose the plastic SOT-23 package because of its low 
manufacturing costs for high-volume products. Using the 
S( >T-2:J package, several modifications were possible that 
we hoped we could lake adv antage of. Before building 
prototype devices, we made a detailed device model for the 
HSt'H-348fi. The model helped us fabricate an optimum de- 
vice with minimum design iterations. 
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Two-dimensional process and device simulators were used 
to model and predici the performance of the HSC'H-3486. 
Diode parameters such as silicon doping, area epitaxial 
layer thickness, metal pad size, and passivation thickness 
were included to study the effects that these process param- 
eters liad on diode electrical performance and ultimately on 
detector performance. A typical sensitivity analysis (Fig. 4 ) 
showed the effect of contact area and epitaxial thickness on 
voltage sensitivity n, assuming an ideal matching circuit. 
The model was also used to check for sensitivity to parame- 
ters that are not directly measurable during processing, such 
as surface states and recombination velocities. The model 
was good for trend analysis but could not be used to predict 
absolute values until devices were fabricated and tested. 

Using the various equations for voltage sensitivity, it is com- 
mon to plot Y2 as a function of the saturation current I s . as 
shown in Fig. 5. for given v alues of Cj, R s , and Since C j, 
R s . R v . and I, interact with one another, it is not simple to 
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70 




Increasing Contacl Diamoler II »m/divl 

Rig 4. Effects of epitaxial layer thickness and contact area on 
VOltag£ sensitivity. 1 = "i.H (ill?.. it|, = Kill k£2. 
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Saturation Current I, IAI 
Fig. 5. Vi ilt.'ige sensitivity as a runctiun of saturation current 

lower Cj. say. without increasing R s . By using the model, we 
were able to select the best combination of these parame- 
ters to maximize the voltage sensitivity at a given frequency. 
The process model ensured that our design was within the 
limits of our existing manufacturing capability. In this way, 
we were able to minimize development costs and time to 
market. 

The fabrication process is relatively simple. Using a heavily- 
doped silicon wafer substrate (to keep R s low), an epitaxial 
layer is grown with tight controls on the doping level, thick- 
ness, and doping transition width. After silicon dioxide and 
nitride passivation, photolithography is used to define a con- 
tact window. A well-controlled metal process is used to de- 
posit the meial. which defines many of the critical parame- 
ters, The metal is etched to an appropriate size for bonding 
in I he plastic- package. The wafer is cut into individual die 
and Attached to a leadframc using a silver epoxy. It is then 
molded into the final plastic configuration. F'ig. (i shows the 
device cross section and die lavoul. 
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Fig. 7. i "ali tila! pel voltage sensitivity for zer» luas Sclinttky 
diodes having R, = SSQand Cj = 0.15 pR R,. = 100 kli. Dots 

show measured values fur 980 MHz, 2.45 <iiiz. and s.h em. 

The packaged device fait be 100% tested for various dc pa- 
rameters such as forward voltage bias Vj and breakdown 
voltage V| )r Many of the dc parameters liave been correlated 
with high-frequency parameters, thus ensuring the perfor- 
mance of each pail and eliminating the high costs associated 
with high-frequency tests. 

Performance 

The initial lots thai were processed after being designed in 
the process anil device simulator performed very closely to 
the predicted values. Minimal model changes w ere neces- 
sary. In fact, the results were sufficiently good that no 
design iterations were necessary and the data sheet specifi- 
cations were set using those lots. Although we did not expe- 
rience the normal kinds of process variation that we would 
expect i ivei a lung peril nl of lime, our ci infidence in the 
model accuracy allowed us to simulate these variations to 
show that the specification would still be met. In addition, 
we could use the model to determine what process and de- 
sice parameters could be changed for future improvements 
to the diode. 
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Fig. 9. Comparison of two zero luas Schflttky diodes. 



Figs. 7 and 8 show actual voltage sensitivity compared to the 
calculated values. 

For comparison with the HSCH-3486 glass package diode. 
Fig. !t shows '/■> as a fund ion of frequency. The different s al- 
lies of Cj, R s . and I s of the two diodes cause the HSMS-2850 
to provide greater performance at frequencies less than 'i 
(III/, while the HSCIKilSli is superior above -t GHz. Because 
of its simpler packaging and testing, the 1 1SMS-2850 is much 
lower in cost than the HSt'll-:J 18(1 

Conclusion 

Hewlett-Packard's newest silicon zero bias detector diode 
has one of the best price/performance ratios on the market. 
We feel that these diodes will become an integral pari of 
many lag applications being designed today and will be con- 
sidered in future designs and technology. They provide ex- 
cellent voltage sensitivity for many of the frequency ranges 
being used in the RF/IE) industry at a very low cost. 
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Fig. 8. Calculated voltage sensitivity of the ri.SMS-2& r >(.l zero 
bias Scholtlcy detector diode. Dots show measured values. 
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the arts and traveling and enioys accompanying his 
wife in her outdoor activities Frederic also has a pas- 
sion for automobiles and high tech gadgets 

Anne C. Hopkins 

Anne Hopkins came to HPS 
Open Systems Software 
Division when Apollo Com- 
puter was acquired in 1989 
She has worked on the de- 
sign and development of 
DCE security services lor the 
I^H^^^ag P asl SIX years, including a 

^^^^^^^ ^ brief interlude as the techni- 
cal protect lead for the HP DCE 9000 1 1 release She 
is currently working on the HP CORBA security speci- 
fication and is HP's technical represerrtatrve to the 
Object Management Group regarding security Before 
coming to HR Anne worked at Wang Laboratories. 





Inc developing OSI network software and at Imagi- 
Tek developing electronic prepress publishing soft- 
ware She is a member of the IEEE Anne was 
awarded a BA degree from Dartmouth College in 
1986. where she maiored in computer science 
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Deborah L. Caswell 



A system architect working 
at HP laboratories for the 
second time in her history at 
HR Debbie Caswell is cur- 
rently responsible for the 
future server architecture 
providing residential broad- 
band services She |o!ned HP 
in 1981 and worked as a 
quality assurance engineer at the Commercial Systems 
Division She then coordinated the HP software met- 
rics program at Corporate Engineering After complet- 
ing her masters degree at Stanlord, she joined HP 
Laboratories foi the first time and woiked on the X 
Window System and various distributed system tech- 
nology. She then led the effort at the Open Systems 
Software Division to products OCE on the HP-UX 
platform belore :ne project was moved to the 
Chelmsford system software lab. She wrote this HP 
Journal article wnile working tor the Network Sys- 
tems Architecture group where she redeveloped the 
DCE programming examples that are shipped with 
HP's DCE product and was a member of the HP 
OODCE design and prototyping team She is profes- 
sionally interested in distributed computing and is a 
member of the IEEE She has coauthored a hnok pub- 
lished by Prentice Hall on software metrics She 
earned a BA degree ai Daitmouth College in 1981 
and an MS degree in computet science at Stanlord 
University in 198B She was a summer intern at Bell 
Laboratoiies In Murray Hill and worked on the user 
interlace for GetSet Ian integrated terminal and tele- 
phunel Born in Summit, New Jersey, Debbie is mar- 
ned and is interested in videography and home im 
provements She also enjoys singing, cross country 
skiing, and snorkelmg. 
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Mihaela C. Gittler 

Born in Romania, Mickey 
Gittler earned a Diploma of 
Electrical Engineering in 
1974 from the Poiytechmcal 
Institute of lasi In 1984. she 
comoleted her masters de- 
gree in computer science at 
the Colorado Slate Univei- 
sity In Colorado. She joined 
tne Desktop Computer Division in 1978 and is now 
working at the Open Systems Softwaie Division. In 
her career at HR she has developed software for data 
computer products, terminal emulators. HP propri- 
etary open systems inetwotksl, and network applica- 
tions She is professionally interested m distributed 
computing and ob|ect-Driented design and has 
worked on distributed systems at HP including HP 
OODCE. which is her current project She designed 
and implemented the HP OODCE registry classes and 
helped to make the HP OODCE prototype a product 





She continues to enhance HP OODCE and to do train- 
ing and consulting with employees and customers foi 
the product Mickey is married and has two boys. She 
likes outdoor activities such as tennis, cross country 
skiing, and backpacking She is interested in the arts, 
traveling, and eight-fingered Norwegian trolls who 
like chocolate 

Michael Zhijing Luo 

Michael Luo is a sollware 
engineer in the Chelmsford 
systems software lab at HP's 
_ ^y»— a 0P en Systems Software 
'V < * I Division He r.umpleted a BS 
f degree in physics in 1987 at 
the Zhongshan University in 
Guangzhou, China and an 
MS degree in computer sci- 
ence in 1990 at the University of Massachusetts 
Alter graduating, he joined HP and has worked on the 
development of OSF/t, DCE. and HP OODCE He is 
currently developing cross-platform client/server 
development tools for Microsoft Windows " and 
HP-UX- 
Luis M. Maldonado III 

Luis M Maldonado III gradu- 
j^^^k ated from the Massachu- 

■ . setts Institute of Technology 

" " m 1992 with a BS degree in 

■ ■ ii'>'iii 

J\ •■l:Vli: ' 

^^tf 'a^^fe interested in distributed sys- 

■^^■■j I terns, While in school he 
"■^^i^B^^^^M completed an internship at 
Digital Equipment Corporation which involved the 
development of distributed applications After gradu- 
ating, he tamed the Chelmsford system software lab 
at HP's Open Systems Software Division He has 
woiked on DCE application development tools, DCE 
IDL, DCE RPC. and the mi., compiler He is currently a 
DCE RPC engineer. Born In New York. New York, Luis 
is an automobile enthusiast and enjoys sports such 
as snowbuarding. mountain biking, fencing, and vol- 
leyball 
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Pankaj Gupta 

A software engineer at the 
General Systems Division 
since 1988, Pankaj Gupta 
contributed to MPE/Xl 

transaction management. 

MPE/XL online backup. HP 

I^Bj 9000. He represents HP at 
■■■■■■■■■■■■■ the X/Open ' transaction 
processing working group Pankaj earned a BS de- 
gree in electrical engineering in 1981 from the Punjab 
University in India He completed his PhD in compuier 
science in 1988 at the State University of New York 
in Stony Brook 




10(1 December 1096 He wlelt-Paekartl Journal 

© Copr. 1949-1998 Hewlett-Packard Co. 



75 Object-Oriented Testing 



Mark C Campbell 

Marcus Campbell was bom 
<n Melrose, Massachusetts 
He earnest an AS degree ■ 

jtfj i; ■ Northern Essex College m 

H if i39 and is currently com 

Open Systems Software Division in 1989 when 
Apollo Computer was acquired by HP As a software 
design engineer, his contributions include testing 
work on DCE. software test development for HP 
CORBA proiects. and designing trie object testing 
framework More recently he has worked on HP ORB 
Plus and is cutrerrtly doing development on the latest 
version of this product Before coming to HP. he 
worked at Lobb Software maintaining business appli- 
cations for hospital reimbursements Marcus is 
married and has five children His hobbies include 
swimming, fishing, and boating. 

David K. Hinds 

A software engineer in the 
Chelmsford systems soft- 
ware lab at the Open Sys- 
tems Software Division. 
David Hinds came to HP in 
1989 when Apollo Computer 
was acquired. He has been a 
reliability engineer for 
Apollo workstations and a 
software engineer responsible for testing DCE and 
the OSF/1 operating system He is also responsible 
for the design and implementation of system testing 
for HP CORBA, He is a member ol the IEEE and is pro- 
fessionally interested in software testing David 
graduated with a BS degree in electrical engineering 
from Northeastern University He is married, has two 
children, and en|oys skiing and sailing 

Ana V. Kapetanakis 

Born in Boston. Massachu- 
setts. Ana Kapetanakis was 
awarded a BS degree in 
electrical engineering at the 
Worcester Polytechnic Insti- 
tute in 1991 and an MS de- 
gree in computer science at 
Boston University in 1995 
She joined the Open Sys- 
tems Software Division in 199? as a software design 
engineer She has worked on DCE testing, HP ORB 
Plus testing, and the obiect testing framework 
design She is currently participating in the develop- 
ment of HP ORB Plus Ana is married and enjoys golf 
and sailing 



Stephen J McFarland 






jining HPs Open Systems 
nftware Division in 1989 



software design on HP 
OODCE At HP he has 
worked as a system test 
engineer a software inte- 
gration engineer and a hardware support engineer 
Before working at Apollo Computer, he was a hard- 
ware systems engineer at Computervision Sieve was 
awarded a BS degree m electrical engineering n 
1984 from Northeastern University Born in Everett. 
Massachusetts, he is married and his hobbies include 
wood carving and gardening. 

David S. Levin 

David Levin was born in Phil- 
adelphia. Pennsylvania He 
joined the Chelmsford sys- 
tems software lab at HFs 
Open Systems Software 
Division in 1 989 when HP 
acquited Apollo Cumputer 
While at Apollo he was the 
manager of software inte- 
gration, and before Apollo he worked at Software 
Arts and Honeywell's Cambridge Information Systems 
lab He is currently the technical lead at HP for the 
distributed computing systems testing team He pre- 
viously worked on systems test and the development 
of a CORBA interface repository for one of the HP 
CORBA projects David graduated with a BA degree 
m philosophy from Clark University in 1972- He is a 
member of ACM He is married and has two sons. His 
hobbies include bicycle commuting, woodworking, 
and skiing 




David J. Miller 




Open Systems Software 
Division in 1989 after HP 
acquired Apollo Computer 
He is currently working nn 
software system testing for 
distributed computing prod- 
ucts He has contributed to 
the development and testing 
of HP ORB Plus and contributed to the design and 
implementation of HP's OMG compliant event obiect 
service Before coming to HP. he was the manager of 
graphics hardware at Apollo and workstation proces- 
sor development at Computervision He earned a 
BSEE in 1971 and an MSEE in 1975 at Northeastern 
University in Boston. He is a member ol the IEE 
Born in Hazleton, Pennsylvania, Dave served in the 
Massachusetts National Guard. He is married and 
has two sons His hobbies include gardening and 
figuring out crossword puules 




J Scott Southworth 

J Scott Southworth itrmed 
HP m 1989 when Apollo 
Computer was acquired He 
worked at HFs Massachu- 
setts language lab and the" 

ware Division As a leaning 
products engineer, he « cv- 
njotly responsible 1c* the 
online help systems Scr distributed ob|ect software 
His previous contributions at HP have included tech- 
nical writing for distributed object software, compiler 
linking, and RISC register usage He has also devel- 
oped online help systems, coded text analysis and 
index analysis software tools, and created a master 
index for 175 documents J Scott was awarded a BS 
degree in urban studies from the Massachusetts 
Institute of Technology m 1972 and an MA degree in 
counseling from 8eacon College in 1979 He worked 
as a technical writer at Digital Equipment Corpora- 
tion and Apollo Computer before coming to HP He is 
a member of the IEEE, the Boston Computer Society, 
and the Society for Technical Communication Profes- 
sionally interested in online help systems and text 
analysis tools, he has published five technical ar- 
ticles spanning distributed obiect computing, hyper- 
text, and indexes. He has also written a book about 
high-tech careers J Scott is mariied, has two chil- 
dren, and enjoys \aii and science fiction writing 
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Andreas Boos 

I^I^IBQ^H Andieas Boos is an R&D 

^^^^^ f ' ' I Division A< 

I m mSit cal P'oject lead, he has been 

» 1 responsible for the engineer 

' «*• I ing of letal momlaring sys- 
k J/d especially signal pro 

^ M cessing hardware and 
* nftware and the support of 

clinical trials He is also responsible tor ASIC devel- 
opment and project documentation His work has 
produced two patents involving the enhancement of 
ultrasound signal processing and the operation of 
medical equipment using bar codes Andreas was 
born in Zwalbach, Germany He was awarded a Di- 
plom Ingemeur in electronics In 1985 by the Univer- 
sity ol Kaiserslautern Upon graduating, he joined the 
HP Boblingen Medical Division Andreas is married, 
has two children. en|Dys listening to all kinds music 
from classical to pops, and likes to play volleyball 
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Michelle Houghton Jagger 

Michelle Jagger is a market- 
mg communications special- 
fc ist ai the Panem Monitoring 
flft^l Division. She is responsible 
i I for worldwide marketing 
0 1 communications lor obstelri- 
\ cal and neonatal products 
within the Medical Products 
Group She came to HP in 
1992, |oining the Boblingen Medical Division As a 
learning products engineer, she was responsible for 
Ihe technical documenlation for fetal monitors and 
telemetry Then as a marketing communications spe- 
cialist, she was responsible for the product position- 
ing and launch of the HP Series 50 T and ol HP Series 
50 OBTraceVue Born in Bristol, England, Michelle 
has a BA degree in modern languages and informa- 
tion systems. She is a member of the British Com- 
puter Society She participates in sports of all kinds, 
especially skiing and tennis. Traveling is also a favor- 
ite because she enjoys learning different languages 
and being exposed to different cultures. 

Giinter W. Paret 

Giinter Paret is the project 
manager for fetal monitoring 
R&D at the Patient Monitor- 
ing Division and managed 
the development of the 
Series 50 T letal telemetry 
system Previously, he 
worked on the development 
of Ihe hardware, software, 
and service support tools for the HP 8040A and HP 
8041 A fetal monitors and was the project lead for the 
development of the HP M1350A. HP M1351A, and HP 
M1353A fetal monitors. He is named as an inventor 
in two patents involving an algorithm that detects 
coincidences in heart rates from different transducers 
and a service tool that activates circuits of electronic 
devices for program modification Gunter joined the 
Boblingen Medical Division in 1980 after earning an 
electrical engineering degree Irom the University of 
Stuttgart He was born in Santiago. Chile, is married, 
and has two children He enjoys playing music on the 
electronic organ, is interested in video techniques, 
and loves "to go awandering" in the Black Forest and 
the Alps. 




Jurgen W. Hausmann 

I A technical marketing engi- 
V^%fc^^H »eet at the Patient Monitor - 

r~^^^^y^M mg Division, Jurgen Haus- 
manri provides technical 
i support and strategies for 

^f^t fetal monitors and letal le- 
'^^^k I lemetry systems He was 
| born in Neuhausen, Ger- 
rm many and was awarded a 
Diplom Ingenieur in electronics from the University of 
Stuttgart in 1982. He |oined HP at the Boblingen 
Medical Division in 1982. Jurgen is married and has 
two children He enjoys outdoor sports such as sail- 
ing on Lake Constance, skiing, and hiking He also 
spends his free time designing electronic circuits to 
automate his house. 
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Rolando R Buted 

Born in Honolulu. Hawaii, 
Rolando Buted earned a 
BSEE degree at the Univer- 
sity uf Hawaii in 1981. Aftet 
graduating he joined HP's 
Microwave Semiconductor 
Division and is now a mem- 
bet of the technical staff al 
the Communications Compo- 
nents Division. Since coming to HP. he has worked as 
an R&D engineer on product and technology develop- 
ment for discrete and IC components for wireless 
communications, and as a manufacturing engineer 
responsible for yield enhancement and product and 
process improvements for discrete diodes He was 
the proiect leader for development ol the HSMS-2850 
Series diodes and was responsible far Ihe product's 
release to manufacturing He is currently responsible 
for developing an improved detector diode. He is also 
working on a high-frequency p-i-n diode swilch and 
on a technology library expansion lor the ISOSAT 
process used for IC components Rolando is active in 
the East Side Academics Mentor program and volun- 
teers in the Newark Unified School District science 
programs He enjoys outdoor activities such as vol- 
leyball, golf, and skiing 



HP-UX 9 " and 10 0 lor HP 9000 Series 700 and 300 compul 
ers are X/Open Company UNIX 93 branded products 

X/Open is a registered trademark and the X device >s a trade- 
mark of X/Open Company Limited in rhe UK and oiher coun- 
tries 

Windows is a U S registered trademark al Microsoft Corpo- 
ration 
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Part 1: Chronological Index 

February 1995 

Broadband Frequency Characterization of < Iptical Receivers I'sing 
Intensity Noise, Douglas M. Bniiey mid Wayne V. Sarin 
1.55-11111 Fiber-Optic Amplifier 

Erbium-Doped Fiber Amplifier Test System, Edgar Lcckel. JUrgen 

Sani/. RnlJ Mutter, t leniens Ritek. and Christian llenlsclict 

Mulu-Quanlum-Wcll Ridge Waveguide Lasers I'm Tunable Exlernul- 
i avity Sources. Tint mala II. Raitganatlt. MicluivlJ. Ltitlowise, 
Patricia A. Berk. Dennis ./. Drrirkstm. William H. Perez, Tim L. 
I!iit)ircll, ami Hariri XI. Hmun 

Measurement of Polarizal ion-Mode riispersion. Hrian /.. Ilcfl'ncr 
a nit Paul R. Ileniilai/ 

■I s Calculus 

The Poincarc Sphere 

The IIPKT>0!IA/D Lightwave Polarization Analyzer 

A New Design Approach for a Programmable t iptical Atlenualor, 
Sii gmar Srliiniill ami llalmii Fischer 

Precision Refleclonicter with Spurious-Free Knhanced Sensitivity. 
Davttl M. llrtitui, Dennis I Deriekson. Litis If. Frrmimte:, ami 
(frttg I). Let 'hem inn nl 

High-Power. Um-Itilemal-Ffcfleclioii. Edge Emitting Lighl-Eimlling 
Diodes. Heniiis .1. Deriekson, Patricia A. Beck, Tim I.. BafiweU, 
David M Bfottn, Jvtie /•.' f^owjust, Forrest G, Kriicrt, Michael .1. 
Lmlnirise, William II I'rre:, Tint mala II Rnnynnutli. (lari/ It. 
Trail, ami Susan H. Sluun 

litter Analysis of High-Speed Digital Systems, ( hrisli>)ihcr M Milter 
ami David I. Mcijuutc 

Auloiualiou of I iptical Tunc -Domain Kcflcctometry Measurements. 
Frank A. Maier ami llanilil Seeger 

Design and Performance of a Narrowband VCt i a! L'H^TIlz. 
Petei R Rnlirish. Christopher J, Madden, Hun/ I.. VanTii/il, ami 
William R Trttlita. Jr. 

Surface Kmilling LaSCX for Mnllimode Dala Link Ap|>licalions, 
Michael R.T Tan. Kenneth II llnhii, Yu Min I). liming, ami 
shiii A'miii Wang 

' ieiierating Short -Wavelength Light I sing a Vertical •Cavity l-user 
Structure. Sliigcrii Sukiigunii. Damn/ E. Mars, ami Suriliide 

Yamada 

A New. flexible Sequencer Architecture for Testing ( oinplcx Serial 
Hit Streams, Rnlierl K. McAuliXfe. -lames I. Henstm. ami GkriStOphet 
II t ain 

Shortening llie Tune to Volume PriHluclion of iligh-Peil'oriiiaiicr 
Standard ( ell ASH s. Jail 0. Mclliiugal ami William I:'. YaWlQ 

A Fraiucwoik lor Insiglil Into the Itupacl of Interconnect on 
0..'!5 i miii VLSI Performance, Prasatl liaje 



Synthesis of LOOM Delay Fault Testable Combinational Circuits by 
Cube Partitioning. William K. Ijnm 

Belter Models or Heller Mgurithms'.' Techniques in lmpro\e Fault 
Diagnosis, Rnhert t\ Ailken anil Peter C. Ma.rirell 

Bridging and StUCk-AI Faults 

Potential Detection 

April 1995 

A Low-< 'ost, High-Performaiiee PARIS! I Workstation with Built-in 
Graphics, Multimedia, and Net WO) king Capabilities. Roger A. 

Pearson 

Die PA 71IKII.I Microprocessor: A I ase Sludy of IC Design Deci- 
sions in a Competitive Environment, Mirk Rass. Pat net, Kttelii I. 
Dat'itl W. Quint, ami William I.. Walker 

Design Methodologies lor the PA 7HM)L( ' Microprocessor, Mirk 
Pass. Terry W. Kluiirltunl. I). Douglas .liisriihsnii, Duncan Weir, 
and Daniel I.. Ualm-rn: 

An I/O System on a Chip. Tin, mas V Spencer, Frank J. Lcltnug, 
t urtis R. McAllister. Anthony I.. Ricdo, Joseph F. Kith, ami 
Hrian K. Armilri 

An Integrated Graphics Accelerator for a Low-Cost Multimedia 
Workstation. Paul Martin 

IIP Color Recovery Technology, Anthony C Bariums 
True Color 

Real-Time Software MPEG Video Decoder on Mulliiucdia-F.nhaiiced 
PA 7I00LC Processors. Ruby ft Let, John P Peek. -Inel Lainli, and 
Kenneth E. Sercrstiu 

Overview of the Implementation nl'the PA THKlLl Multimedia 
Enhancements 

HPTeleShare: Integrating Telephone ( inabilities on a ( omputer 
Workstation. S. Paul Tucker 

Caller-ID 

Call Progress, DTMFTones, mid Tone Del ection 

Product Design of the Model 712 Workstation and External 

Peripherals, Arlen L. Rocsner 

Development of a Low-I lost, High-Perlbrtnance, Multiuser Business 

StTVW System, Dennis A. tUarers. tieraiil M Enkcrlin. ami Karen 

I.. UvrWa 

HP Distributed Smalltalk A Tool for Developing Distributed 
Applications, Eileen Keremilsis ami Ian J Futlei 

i Ibject Management firoup 

A Software Solution Broker for Technical < onsult.uils. Mamii/ 
Yousefl, Add Qhonairtty, ami Wuii Printer 

HP Software Solution Broker Accessible Products 
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Bugs in Black and White Imaging IC Logic Levels with Voltage 
contrast, Jack n /(<■»;<•/ 

Component and System Level Design-for-Tcslahilily Features 
Implemented in a Family of Workstation Products, liidcnt I. 
Dervtsoglti and Michael llicchetti 

June 1995 

Capillar} Electrophoresis: A Product of Technological Fusion, 
Robert ft. Hollo n ay 

A New lligli-Perfoniiaiice ( 'apillary Electrophoresis Instrument, 
Fred Strohmeier 

i apillary' Electrophoresis Applications 

IIP CE Technology Transfer 

Industrial Design of the HP CE Instrument 

A High-Sensitivity Dioile Array Detector for < tn-( 'oliiinii Detection in 
Capillary Electrophoresis, Patrick ffaltenbach 

Capillary Handling in Ihe IIP Capillary Elect rophoiTsls Instniiueut, 

by Hans-Peter Ztmmermantn 

Rapid Prototyping for the HP CE Project 

Sample Injection in Hl'CE. Werner Schnciilcr 

IIP CE Separation < onlrol Electronics and Firmware. Frit: Bi'k. 
Franz Berlsch. mid Klaus Witt 

A User Interface fur Capillary Electrophoresis. Altciu Rilzinann 
n mt Klu us Will 

Development of a Common ChemSlation Architecture 

Reproducibility Testing of the HP CE Instrument, vu-ikc Jeyle 

The Impact of Column Technology on Protein Analysis hy Capillary 
Electrophoresis: Surface Coatings and Analytical Approaches for 
Assessment. Still// A. Sin illicit/ timl Monikti Diltmanii 

A New High-Sensitivity Capillary Electrophoresis Detector Cell and 
Advanced Manufacturing Paradigm, Gary II. (inrtltm. Riclimil I'. 
Tt'ltn. iiml Hrnrit/iic AS. Murtins 

I IP I >isk Array: Mass Storage Fault Tolerance for P( ' Servers, Ttmi 
A. Skrir mitt Michael It. Rusmick 
An l hervievv of Raid Technology 

ci Hit iLSoftHcnch: An < "pen Integrated CASE Environment, Ohetyl 
t nriiiii littti 

Development and I'se of Electronic Schematic Capture in the 
Specification and .Simulation of a Slruclured-Ciisloiii ASIC, David A. 
fin rt/t it hi 

Design and Development ofa 120-MHZ Bus Interface Block Using 
Standard < ells and Automatic Place and Route Tools, Robert F.. 
Ili/tiii 

August 1995 

Introduction to KIOVIi-AnvLAN and the IEEE 802.12 Local Area 
Network Standard. Alan ft. Altirrrlit anil Patricia A. 'Dialer 

Cable Types 

Other Network Technologies 

Demand Priority Protocol. Aitxn it AlbrecM, Micimri i'. Sprutt, 

Patricia A. 'Dialer, anil Givyory C.A. Walsnn 
Network Protocol Layers 

Physical Signaling in lOOVf i-AnyLAN. Alistair X. Coirs. David (!. 
Cunningham, Joseph A. Cmrin, Jr., Daniel j. Dave, ami Steven G. 

Mclhley 

Cross Talk in Unshielded Twisted-Pair Cables 

Multilev el Signaling 

Cross Talk Analysis 

i ipiical-Fiher Unks for UKMi-AnylAN 



Coding in lOOVG-AnyLAN, Simon BkC. ' rtrueh mut Jonathan 
Jethoab 

IEEE SII2.:i and 802.5 Frame Formats 

Polynomial Arithmetic and Cyclic Redundancy Checks 

Multimedia Applications and lOOVG-AnyLAN. John R. Griiihani 
mill Michael I' Spratl 
Remote Bridge Example 
Higher-Level Protocols 
Related Projects 

lOOVG-AnyLVN 15-Poit Huh Design, Lisa S. Bmivu 
Invalid Packet Marker 

HP AccuPage 2.0: A Toolkit for High-Quality Docunieiil Scanning. 
Slcrcn L Webb. Steven G Henry. Kevin S. Buike, ami Georyp 
Prokop 

An 11.8-in Flat Panel Display Monitor. DacitlJ. Hnilyc, llrailly J. 
Foster. Steven J Kominriiscli. ami Tom J. Scurhy 

Liquid Crystal Display Technology 

Product Design orthe HP S1010A Flat Panel Display 

A Note About VRAMs 

Apply mg an Improved Economic Model to Software Buy-versus- 
Huilil Decisions, Wesley II Hit/tiki 

Benchmark Standards for ASIC Technology Evaluation, Antonio A. 
Martinez, AlakeS. Iiliamlia. ami Henry //.IV. Lie 

October 1995 

IIP PE/SoIidDesigner Dynamic Modeling for Three-Dimensional 
Computer- Aided Design, Klaus-Peter Falilbiisch ami Thomas I). 
Hoser 

User Interaction in HP PE/SolidDesigner, Berlltoltl Huy. Gcrliartl 
J.Wulz. ami Markiis Kiihl 

Enhancements in Blending Algorithms. Stefan Frcilati ami Knrstcn 
Opilz 

t (pen Data Exchange with HP PBBolidDes^ner, Peti t J SchUd, 
Woifynnt/ Klein in, Gerhmil J. Wat-, anil llermmtn .1. Ruess 

Providing CAD < Inject Management Services through a Base Class 
Library, Clous Brod a ml Max it. Kublin 

Exception Handling and Development Support 

Ficcforin Surface Modeling, Michael Melzyer and Sabine Fismiinu 

Common Lisp 88 an Embedded Extension Language. Jens Kilian 
and Heiuz-Peter Anttit 

Boolean Set ( Iperations with Solid Models. Peter If. Ernst 

Fighting Inaccuracies: Using Perturbation to Make Boolean 
( Iperations Robust 

A Microwave Receiver for Wide-Bandwidth Signals. Hubert J. 
Arinanlriiitl 

Firmware Design for Wide-Bandwidth IF Support and Improved 
Measurement Speed 

The HP 89400 Series Vector Signal Analyzers 

An IF Module for Wide-Bandwidth Signals. Robert J. Arinmitrimt, 
Tcrivncc R. S'oe. Cliris/n/iher F. Stewart, and Leiiuanl M. Weber 

The Log Weighted Average for Measuring Printer Throughput, lohn 
•/. Cassidy. Jr. 

December 1995 

DCE: An Environment for Secure Client/Server Computing, Michael 
M. Kuny 

Adopting DCE Ifechnology for Developing Client/Server Applica- 
tions. Paul Lloyd and Samuel I). Ilnmiritz 
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DCE Directory Services. Michael M. Kong ami David Truong 

X/Upen Federated Naming. FJizalielh A Martin 

HP Integrated Djgin. ./n;ir /?. Marrus. Xatanvri Kumar, niul 
La icrence .1. Rose 

Tile IK E Security Service. Frederic (Hitler ami Anne C. Hupkins 

An Evolution of DCE Authorization Services, Drhorah I.. Caswell 

An Object-Oriented Application Framework for DCE-Based 
Systems. Miliaria ( '. (littler. Michael 2. Lao. and Luis M 
Maliluiiadu 
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Railroad StVOct 

Random testing 29/Apr. 

Rapid prototyping 29,'June 

RC delay 101/Fcb. 

Reader 94/Dec. 

Read only tags 9 •I/Dec. 

Read/write tags 94/Dec. 

Real-time clock :39/Apr. 

Receiver clvaraclerization. 

optical fi/Feb. 

Receiver, microwave 80/Oct. 

Recoverable imeueing service . . (iS/Bec 

Rectangular area fill 44/ Apr. 

Refcount entities 53/Oct. 

Reference 29/Dec. 

Reflection of solids 7S/Ocl. 

Reflectometer, precision optical . . 39/Feb. 

Reflectometry, optica] 

low-coherence 13/Fcb. 

Regional centralized data 

architecture 73/Dec. 

Registry 37. 41/Dec. 

Relation solver 7. 13/Oel. 

Relations 53/Oct. 

Relative disl'mgiiisheii name 25/Dec. 

Ri'lative file 67/Dec. 

Relative intensity noise (R1N) 8/Feb. 

Relaxing 25/Oct, 

Remote bridge 35/Aug. 

Remote procedure call ( BPC) 
8<i/Apr.. 8/Dec. 

Remote procedure call (RP< i 

interfaces 2S/Dec. 

Repeater chip I()/Aug 

Replenishmenl control 41/.Iunc 

Replenishment system 14. 34/June 

Reproducibility testing 50/June 

Request window 1 1/Aug. 

Resolution 45/Aug. 

RF module 81/Oct, 

Ridge laser 23/Feb, 

Ridge structure 43/Feb. 

Ridge waveguide laser 2()/Feb. 

RI.C lankcirciiil 91/Oci. 

Robustly path delay fault 

testable (RPDFT) 105/Feb. 

Rolling ball blend 25/(>ct. 

Romulus 7/( id. 

Root of a namespace 23/I)cc. 

Root hub 14/Aug. 

Round-robin node selection 13/Aug. 

Rounding 21. 25/Oct. 

RPCNSIAPI 11.24/Dcc 

BPC protocols ui/ivc 

RFC server entries 2oVDee 



S 

Sample and electrolyte handling 29.Junc 

Sample injection 32/Jitne 

Saturation arithmetic 6-VApr. 

Saturation logic 667Apr. 

Scaling 49. 55/Aug. 

Scaimer software I - \h-j 

SCSI mitgarcll 41/Apr 

Second-harmonic generation 72/Feb. 

Secondary' storage 72/June 

Secret key 41/1 )ec. 

Secure communication 45/Dec. 

Security 90/Apr, 34/Dec. 

Security server 41/Dec. 

Security technologies 34/Dec 

Semantic/presentation split .. 88, !l7. Api 

Sensitivity 22/June 

Sensitivity gain, bubble cell lifi'.hinc 

Separation control 30/June 

Separation environment 1 I/June 

Separation principle . (VJtme 

Separation suhunil 38/June 

Separation unit kQflune 

Sequencer arcliitecture 7(i/Feh. 

Serial device test sciiuencer 7(VFeb. 

Serial test card 76/Feb. 

Serial Tesl Language 70, 85/Feb. 

Serial test sequencer 82/Feb. 

Server classes 55/Dec. 

Service ticket 42/Dec. 

Servos 39/Junc 

Sheet 75/Ocl. 

Short-wavelength laser 72/Fch. 

Simple average 104/Oci 

Simple dithering 52/Apr. 

Simple weighted average . 104/Oet. 

Single sign-on problem 39/Dec. 

Single-step login 34/Dec. 

Singularity 2H. 32/1 let 

Sitiiisoidaljillei ."i,'t/Fi'b, 

Skinning (ifi/Ocl. 

Small point-size characters 4(i/Aug. 

Smalltalk 85. 94/Apr. 

Smooth operator Klti/Feh. 

Soft links 26/Dec. 

Si il l wan I uiy-versus-l mill I 

decisions til/Aug. 

Software caches 85/()cl. 

Software raid architectures . . 73/June 
Software Solution Broker . 93/Apc 

Software testing 75/Dec. 

Software video support 48/Apr. 

Solid modeling design system ... rVOct 

Source code control 83/-lunc 

Spectral library i2/.iun<- 

Spectrum analyzer 80/Dct 

Spider diagram 81/Apr. 

Spine 27/Oct. 

Spline 82/Oct, 

Spline library lil/Ocl, 
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Spurious responses, EEI.ED 44/Feb. 

Standard cells 91/Feb.. 92/,Iune 

State manager 58/Oci. 

Step gains 95/Oct. 

STEP (standard for exchange 

of product model data) 13/Oct. 

Stop register/split Iransfer 47/Apr. 

Stray light 22/Jline 

Slripeset 77/June 

Stuek-at-faults 110/Feb. 

Structured file system (57/Dcc. 

Subcortex) 29/Dec. 

Superscalar execution 20/Apr. 

Surface comings 57/.Iune 

Surface emiiting laser (>7/Feh. 

Surface modeling lil/Oct. 

Surface modified capillaries 58/.lune 

Sweeping (58/Ocl. 

Switching 10/Aug. 

Symbol synchronization 

algorithms 78/Feb. 

Synchronously I lined fillers 89/Oct 

Synlhesis and routing 23/Apr. 

System adminislrntion 70/Dec. 

System adminisl ration manager 

(SAM) 71/Dee. 

T 

Tag 94/Dec. 

Tangential Intersections 28, 32/Oci. 

TAP/SAP controller 108/Apr. 

Target transmission l ime 37/Aug. 

Technological domain 97/Feb. 

Technology constanl 67/Aug. 

Telemetry receiver 90/Dce. 

Telemetry transmitter 85/Dee. 

Telephony fl/Apr. 

Telescrviccs project 38/Aug. 

Temperature conl nil 38/,Iune 

Test developers 76/Dee. 

Test liarness 75/Dec. 

Test management subsystem 7S/I)ec. 

Test system. EDFA 13/Feb. 

Test system, oplical fiber 57/Feh. 

TestCase class 78/Dec. 

TestEnwonmenl 77/Dec. 

Testing complex serial bit 

streams 7(i/Feb. 

Thread-to-TID 63/Dec. 

Tlireads 7/Dec. 

Three-tiered architectures 62/Dec. 

Tltreshold -I5/Aug. 

Throw statement GO/Dec. 



Ticket-granting lickel (TOT) 42/Dec. 

Time-delay discriminator 99/OcL 

TLB I8/Apr. 

TLB (translation lookaside 

buffer) 18. 79/Apr. 

TMIn 23/Feb. 

TM-XA 64/Dce. 

TOCO driver 88/Dec. 

Token ring (IEEE 802.5) 6/Aug. 

Tone detection 73/Apr. 

Tool body 7, 8/Ocl- 

Topology 25. 29, 03, 76/Oct. 

Transiiction(s) 58/( let., Ii. r >/Dec. 

Traiisiiction manager 63/Dec. 

Transaction processing 61/Dec. 

'liansaclion processing monitor . OS/Dec. 

Transactional RPC 03/Dec 

Transceiver chip Il/Aug. 

Transfonualion algorithms 78/Feb. 

Transition curves 31/Oct 

Transition frequency (f-r) 97/<)ct. 

Transponder 94. 95/Dec. 

Trimmed mode 39/Oel. 

Trimmed parametric mode 10/Ocl, 

Trimming 28/Ocl. 

Tiyptic digest analysis 12/June 

True color 52/Apr. 

Try block (Ml/Dec. 

Tunable laser sources 20/Feb. 

Two-level circuit IfMVFeb. 

Two-phase locking 65/1 )ec. 

Two-tiered architecture 61/Dec. 

U 

Unbiased rounding 04/Apr. 

I 'ndo operations 59/Oct. 

Unforgeable identities 50/Dec. 

Universal unique identifier 

(UTJ1D) 9,23.41/Dec. 

fJnpaced byte wide 37/Apr. 

I'npaced word wide 37/Apr. 

Unshielded twisted pair (I TP) .... O/Aug. 

Untrimmed mode 39/Oct, 

Update handlers 59/Oct. 

Upgrading existing networks 10/Aug. 

User interface builder 22/Oct. 

I Iser interface, capillary 

electrophoresis 44/June 

User interface, 

HPPE/SoliilDesigner 14/Oct. 

Uterine activity measurement ... 88/Dec. 

Utiliiy classes 56/Dec. 

UVAis absorpl ion detection 11/June 



V 

Varati or diodes 93/Ocl. 

Variable-hand width design 89/Oct. 

Variable-radius blends 25/Ocl. 

VCO, 282 THz 63/Feb. 

Vector signal analysis 83,'<>cl. 

Vector signal luialy/ers 87/Ocl. 

Verilical ion methodology 25/Apr. 

Vertex nonmanifold 75/OCt 

Vertex region* 25, 31" " l 

Vertical-cavity laser 72/Feb. 

Veitical retrace 52/Aug. 

Video standards 00/ Apr. 

Virtual functions (iO/Dec. 

Virtual shelf 93/Apr. 

Vision, computer 68/.Iune 

VisualWorks 9:1/Apr. 

Voice mode operation 72/Apr. 

Vollage contriLsl imaging 102/Apr. 

Voltage, current, or power control . lO/.lune 

Voltage measurement 40/June 

Voltage sensitivity 96/Dec. 

VRAMs 43/Apr. 56. 59/Aug. 

VSVNC 52/Aug. 

w 

Wall 102/Apr. 

Wavelength scanning method . . . 30/Feb. 

Window accelerator 43/Apr. 

Wire capacitance ioo/Feb. 

Wire geometry 98/Feb. 

Wire load models 92/Feb. 

Wireframe mode Il/Oct. 

Work-plane set 64/Ocl. 

Workstation, multimedia 6/Apr. 

Write-ahead logging 63, 65/Dec. 

XYZ 

XBAR 69. 70/Apr. 

X.500 25/Dec. 

XDS/XOM APIs 24/Dee. 

XFN API 29/Dec. 

XFN enterprise policies 32/Dec. 

XFN protocols 30/Dec. 

X/Open Federated Naming (XFN) . 28/Dec. 

YCbCr 62/Apr. 

YlG-tuned filter (YTF) 81/Oct. 

Zero bias diode 94/Dec. 

Zero Injection effect 52/June 

Zipping 2fVOct. 



ill) December IflMHewtettttcteudJqan^ 
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COBOL SoftBeneh June 

COBOL'C SoftBeneh lime 

COBOL'C-- SoftBench June 

HP AccuPage \ug 

IIP AccuPage HO Aug. 

UP ArtvanceStack 100VG Hub 15 (HP J2410A) Aug. 

HPAdvanceStack llMAGSNArP'Bridge Module! HP JJ4MA) Aug. 

HP ChemStation June 

HP Disk Amy June 

IIP Distributed Smalltalk Apr. 

HP Enrina/MOO . ... Dec. 

Ill' Integrated Login Dec- 
HP i)i UK E Dee. 

HI' PE ( ouipleiueiitary Application Program (CAP) . ... Oct 

HPPE'DDS-C Ofi, 

HPPE'MEIO Oct 

IIP PE/ME30 ( let. 

IIP PE/Sheet Advisor Oct. 

HP PE'SoliriDesigner Oct 

IIP PESiirfaeeSlyler Del. 

HP PE/WorkManager Oct 

IIP Precision Engineering Systems Oct 

HP Series 50 T Fetal Telemetry System I HP Ml 31 OA ) Dec 

HP Software Solution Broker Apr. 



HP TclesJiare Apr 

HP !(V10<>\ G Selectable ISA, EISA, and 

PO Adapteis(lUM:KTCAJ2-.77A.and J2585A) Aug. 

HP 100VG-AiiylAN/Jl00(l(IIPJaM5AA.Ji>SSt*) Aug. 

HP IOOYGAnyLAN Development System (HP E2463A) Aug. 

HPSHUOA Flat Panel Display Aug 

HP GlfiOOACE Instrument June 

HP SDO0 Series 90S. 918. B2S. and (MS Apr. 

HP 8070 Board Test Family Feb. 

HP B166A Optical Attenuator Feb. 

HP Sltisc Tunable Laser Source Feb. 

HPS-HUB Precision Reflectometer Feb 

HP S5tl!i.VB Lightwave Polarization Analyzer Feb. 

IIP 9000 Series 71)0 Models 71280 and 71280 Apr. 

lIPMIKMlSeries sol) Models F.J". E:i.".. El", ami E"» Apr. 

HP TtlfillA IF Module Oct. 

HP 71o01B. litter and Eye Diagnun Analyzer Feb. 

HP 71H10A Wide-Bandwidth Heceiver ( let. 

HP S Mini) Series 200 EDFA Test System Feb 

HP S 1 7(H) Series 100 Remote Fiber Test System Feb 

HP 8!M00 Series Vector Signal Analyzers Oct 

HS.MS-285x Silicon Detector Diodes Dec. 

SemceGuard/TX Dec. 

Switchover/1 Dec. 



Part 4: Author Index 



AiUcen, Robert G Feb 

Albrechl. Alan R . . Aug. 

Armantroui. Robert J Od 

Amdl. Heinz Peter ... Oct 

Arnold. Bnan K Apr. 

Bagwell. Tim I. Feb 

Baney. Douglas M Feb. 

Barkans. Anthony C Apr. 

Bass, Mick Apr 

Balletic. Martin lone 

Beck. John P, Apr. 

Beck, Patricia A Feb, 

Bek. Fritz lime 

Benson. James L. . Feb 

Benzel. Jack D Apr. 

Bertsrh, Franz June 

Bhandia, Aloke S Aug. 

Blancharri, Terry . . Apr. 

Boos, Andreiis Dec. 

Bowers. Dennis A Apt 

Biaun, David \I Feb 

Bind, t 'huts Oct. 

Brown. Lisa S . . Aug. 

Burgoon, David A June 



Burke. Kevin S Aug. 

Billed. Rolando R Dec. 

I am. ( iiristophcr B Feb. 

Campbell, Mark C Dir. 

('annichael. < "beryl lime 

( assiriy. John J.. Jr. Net 

Caswell, Deborah L Dec. 

Coles. AlislairN Aug. 

Crouch, Simon EC Aug. 

Cunningham, David G \i m 

Ciiivio. Joseph A.. Jr. Aug. 

Derickson. Dennis.) Feb. 

Dervisoglu. Bulent 1 Apr. 

Dinter, Raonl fame 

Ditimaiin, Momka line 

Dove, Daniel .1 Aug. 

Eistnann, Sabine Oct. 

Enkerlin. Gerard M Apr 

Ernst. Peter II Oct 

Fahlhiiscli. Klaus-Peter I let 

Fernandez. Luis M Feb. 

Fischer, lialmo Feb 

Foster, Brarily .1 \uu. 

POUqUCt, Julie E Feb. 



Freitag, Stefan 1 1< i 

Fuller, lan J Apr. 

( dioneimy, Ariel Apr, 

i littler, Frederic Dei 

< littler, MihaelaC Dec 

Gordon, Gary B hme 

I irirtham, John R Aug. 

Gupta, PankaJ Dec. 

Halm. Kenneth II Feb. 

Kalperin, Daniel L Apr. 

Hanson, Del Aug 

tiausmann, Jiitgea W» Dee. 

Ileffner, Brian L Feb. 

Henry. Steven G Aug. 

KentscheL Christian Feb 

llemday. Paul R Feb. 

Iligaki. Wesley 11 Aug 

Hinds, David K Dec 

Hodge, Davie 1. 1 Aug. 

lioiiouay Robert R .1 

Hopkins, Anne C Dec, 

Horowitz. Samuel D Dim 

lloiing, Yii -Miu D Feb 

HugtBerthold Oct 
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lshak. Waguih Feb. 

Jagger, Michelle Houghton Dec. 

Jedwab, Jonathan Aug. 

.legle, I Alike June 

Josephson. D. Douglas Apr. 

Jiingcnnan, Roger Feb. 

Kaltenbach, Patrick June 

Kapetanakis, Ana v Dec. 

Kellert, Forres! G Feb. 

KereniilsLs. Eileen Apr. 

Kilian, Jens Oct. 

Klenun, Wolfgang Oct 

Kncbel. Patrick Apr. 

Kommrusch, Sieven J Aug. 

Kimg. Michael M Dec. 

Kulilin, Max R. Oct 

Kiihl. Markus Oi l. 

Kumar, Navaneet Dec. 

Lam, William K. Feb. 

I.anib, Joel Apr. 

U>('henunanl. Greg I) Feb. 

U'ekel. Edgar Feb. 

Lee. Ruby li Apr. 

l-eltang. Frank J Apr. 

Levin, David S Dec. 

Lie. Henry H.W. Aug. 

Lloyd. Paul Dec. 

Ludowisc, Michael.) Feb. 

Luo. Michael Z Dec. 

Madden, Christopher J Feb. 

Maicr. Frank A Feb. 

Maldonailo Luis M Dec 

Marcus, Jane B Dec. 

Mars, Danny E Feb. 

Martin, Elizabeth A Dim-. 

Martin. Paul Apr. 

Martinez, Antonio A Aug. 

Martins, Henrique A.S June 



Maute, Alfred lime 

Maxwell. Peter C Feb 

McAllister. Curtis R Apr. 

McAuliffe, Robert E Feb. 

McDougal. Jay D Feb. 

McFarland, Stephen J Dec. 

McQuate, DaVid J Feb 

Mctliley. Sieven G Aug. 

Mei/.gcr. Michael Oct. 

Miller, Christopher M Feb. 

Miller. David. I Dec, 

Miiller. Rolf Feb. 

Murillo. Karen 1. Apr. 

Nakagawa. Shigeru Feb. 

Noe. Terrence R Oct. 

t tpitz, Karsieti < M. 

Orih. Joseph F. Apr. 

Parel. (i (inter W. Dei-. 

Pearson, Roger A Apr. 

Perez. William H Feb. 

Prokop, George Aug. 

Quint, David W. \pi 

Ride. Prasad Feb. 

Ranganath. TiruinalaR Feb. 

Rehder, Wall' Apr. 

Ricihetli. Michael Apr. 

Riccio, Anthony I Apr. 

Rice. Thomas A Oi l. 

Kitzniann, Alwin June 

Robrish. Peter R Feb. 

Roesner, Arlen L Apr. 

Rose. Lawrence J Dec. 

Roser, Thomas D Ocl. 

BQCk, Clements Feb. 

Ruess, Hermann J Oct. 

Rusnack. Michael R lune 

Ryan, Robert E hine 



Sang. Jurgen Feb. 

Sehild. Peter J Ocl. 

Schmidt, Stegmar Feb. 

Schneider. Werner lune 

Searby, Tom .1 Aug. 

Sceger. Harald Feb. 

Severson, Kenneth E Apr. 

Skeie, Tom A lune 

Sloan. Susan R Feb. 

Sarin, Wayne V. Feb, 

Southworth, J. Scott Dec. 

Silencer, Thomas V. ■fft' t 

Spratt. Michael P. Aug. 

Stewart. Christopher E Oct. 

Slrohnieier, Fred June 

Swedberg Sally A Iune 

Tan. Michael R.T. Feb. 

Telia, Richard P. June 

'Dialer, Patricia A Aug. 

Trott, Gary R Feb. 

Truong, David Dec: 

Trulita. Jr.. William R Feb. 

Tucker, S. Paul Apr. 

VanTuyl, Rory L Felt. 

Walker, William L Apr. 

Walz. Gerhard J Oct. 

Wang. Sliih-Yuaii Feb. 

Watson. Gregory C.A Aug. 

Webb, Steven I Aug. 

Weber. Leonard M Ocl. 

Weir. Duncan Apr. 

Wiederoder. Herbert lune 

Witt. Klaus lune 

Vamada. Norihide Feb. 

Young, William E Feb. 

Yousefi. Manny Apr. 

Zimmermann, Hans-Peter June 
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